Method and system for managing multiple catalogs of files on a network

ABSTRACT

Systems and methods have been developed for managing multiple catalogs of files on a network. The systems and methods may manage a catalog of files with rights for sale and a catalog of rights presented for free public use. The systems and methods may manage these multiple catalogs via determining when one file should be moved from one catalog into another. The systems and methods may manage rights presented in the files, including rights offered for sale, rights offered for free use, where the managing may include changing the classification of those rights based on data relating to the files. The systems and methods may provide the ability to a user to research whether rights in the file are for sale.

RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application No.60/774,924 filed Feb. 17, 2006.

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent file or records, but otherwise reserves all copyrightrights whatsoever.

BACKGROUND

The expansion of the Internet and the World Wide Web (“web”) has givencomputer users the enhanced ability access a large variety of digitalcontent. The digital content can take many types of forms, includingmedia. For example, the digital content may be media that a user maylisten to and watch through their computers. The digital content mayalso be media that the user creates on the user's computer, and then“uploads” to another computer, such as a server, in order to share withother users. This media can be in the form of audio music, music videos,television programs, sporting events or any other form of audio or videomedia that a user wishes to watch or listen to.

The Internet allows users to experience content, share content, downloadcontent, upload content and create content. The Internet is often,therefore, used as a tool to distribute and copy content, sometimesillegally or in violation of rights owned in that content. For example,music piracy using the Internet is a significant problem for owners ofrights in music. Another example, is the violation of copyrights inimages that are easily copied and reformatted using the Internet.

Effective enforcement is difficult using the Internet becauseenforcement relies on identification of content that is violatingrights. Most search engines rely on text tags, and therefore, it isdifficult to locate automatically content that might be copied or usedin violation of rights. Additionally, a search engine that relies solelyon text tags of a content file to confirm a violating content file'sexistence will miss a content file that has been renamed. Thereby apotential infringer may use a content file with near impunity byrenaming the file.

While a user may be encouraged to use a file wantonly by the inabilityto find the owner of the file, that user may also be deterred from usinga file by the fear of being subject to legal sanctions for use inviolation of the owner's rights. Digital rights management (DRM) systemsand methods exist to control access to content files. Such DRM systemsand methods may be tailored to specific uses and/or players. DRM systemsoften restrict access to content files by disabling the content for play(i.e. perception) on disallowed players, or by disabling the recordingof the content onto certain types of media (e.g., copying music onto aCD).

SUMMARY

Systems and methods have been developed for managing multiple catalogsof files on a network. The systems and methods may manage a catalog offiles with rights for sale and a catalog of rights presented for freepublic use. The systems and methods may manage these multiple catalogsvia determining when one file should be moved from one catalog intoanother. The systems and methods may manage rights presented in thefiles, including rights offered for sale, rights offered for free use,where the managing may include changing the classification of thoserights based on data relating to the files. The systems and methods mayprovide the ability to a user to research whether rights in the file arefor sale.

In one aspect the disclosure describes a method which includespresenting for public use on a publicly accessible network a free rightin a first content file, periodically calculating a popularity index forthe first content file, the popularity index being based on currentusage data of the content file, and based on a comparison of thepopularity index with a threshold, offering for sale on the publiclyaccessible network a pre-designated right in second content file.

The pre-designated right in the content file may be different from thefree right in the content file. The free right in the first content filemay be a right to access the first content file in a first format andthe pre-designated right in the second content file may be a right toaccess the second content file in a second format. The free right in thefirst content file may be a right to render the first content file froma remote location and the pre-designated right in the second contentfile may be a right to copy the second content file to a permanentcomputer-readable medium.

The pre-designated right in the second content file may be a right inthe second content file authorized by an owner to be offered for sale.In one embodiment, the owner owns a master right in the first contentfile and the master right in the second content file, the master rightincluding a right to distribute the free right and a right to distributethe pre-designated right. In another embodiment, the method includesselecting the pre-designated right from a plurality of differentpre-designated rights, wherein each of the plurality of differentpre-designated rights is a different right authorized by the owner to beoffered for sale in the second content file. In another embodiment, themethod includes receiving the second content file from the owner, andreceiving a request from the owner to present for public use on thepublicly accessible network the free right in the first content file.The usage data of the first content file may be data selected from userrequests for the first content file, user ratings of the first contentfile, and user ratings of a different commonly owned content file.

The method may include creating the threshold based on informationreceived from the owner. The method may include limiting distribution ofthe free right in the first content file based on the comparison of thepopularity index with the threshold.

The method may include receiving an unknown file, and matching theunknown file to the second content file. In one embodiment, the methodmay include calculating the popularity index in response to matching theunknown file to the second content file. Calculating the popularityindex may be performed based on unknown file usage data. The unknownfile usage data may include user requests for the unknown file.

In another aspect, the disclosure describes a method which includespresenting for public use on a publicly accessible network a free rightin a content file, receiving a request from a user to purchase a firstright in the content file, determining whether the first right in thecontent file is authorized by an owner to be offered for sale, whereinthe owner owns the first right in the content file, and, if the firstright is authorized by the owner to be offered for sale, offering thefirst right in the content file for sale to the user.

The first right may be different from the free right. The first right inthe content file may be a right to access the content file in a firstformat and the free right in the content file may be a right to accessthe content file in a second format. The first right in the content filemay be a right to render the content file from a remote location and thefree right in the content file may be a right to copy the content fileto a permanent computer-readable medium. The owner may own a masterright in the content file, the master right including a right todistribute the free right and a right to distribute the first right.

The method may include receiving, from the owner, a request to offer thefirst right in the content file for sale based on receiving the requestfrom the user to purchase the first right in the content file, whereinthe receiving the request from the owner is performed before thereceiving the request from the user. The method may include, if thefirst right is authorized by the owner to be offered for sale, offeringthe first right in the content file for public sale on the publiclyaccessible network. The method may include limiting distribution of thefree right in the content file based on the receiving the request fromthe user.

In another aspect, the disclosure describes a system which includes acommunity server which presents for public use on a publicly accessiblenetwork a free right in a content file, a cataloging engine whichcalculates a popularity index for the content file, wherein thepopularity index is based on current usage data of the content file, andwherein the community server offers for sale on the publicly accessiblenetwork a pre-designated right in the content file based on a comparisonof the popularity index with a threshold.

The community server may receive a request from a user to buy thepre-designated right in the content file, wherein the community serverpresents for sale on the publicly accessible network the pre-designatedright in the content file based on the request received. Thepre-designated right in the content file may be different from the freeright in the content file. The first right in the content file may be aright to access the content file in a first format and the free right inthe content file may be a right to access the content file in a secondformat. The first right in the content file may be a right to render thecontent file from a remote location and wherein the free right in thecontent file may be a right to copy the content file to a permanentcomputer-readable medium.

The pre-designated right in the content file may be a right in thecontent file authorized by an owner to be offered for sale. The ownermay own a master right in the content file, the master right in thecontent file including a right to distribute the free right in thecontent file and a right to distribute the pre-designated right in thecontent file. The system may include an arbitration engine which selectsthe pre-designated right from a plurality of different pre-designatedrights, wherein each of the plurality of different pre-designated rightsis a different right in the content file authorized by the owner to beoffered for sale.

The community server may receive the content file from the owner, andthe community server may receive a request from the owner to present forpublic use on the publicly accessible network the free right in thecontent file. The community server may create the threshold based oninformation received from the owner. The usage data of the content filemay be data selected from user requests for the content file, userratings of the content file, and user ratings of other content filesassociated with the owner. The community server may retrieve usage dataof the content file from a database selected from a ratings database, auser information database, and a metagraphics database.

The community server may limit distribution of the free right in thecontent file based on the comparison of the popularity index with thethreshold. The community server may receive an unknown file. The systemmay include a comparison engine which determines whether the unknownfile is related to the content file based on matching a bit print of theunknown file and a bit print of the content file. The cataloging enginemay calculate the popularity index if the unknown file is related to thecontent file. The cataloging engine may calculate the popularity indexbased on unknown file usage data. The unknown file usage data mayinclude user requests for the unknown file.

A BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a system for monitoring and moderating files over anetwork.

FIG. 2 illustrates an embodiment of a system implementing a digitalmarketplace.

FIG. 3 illustrates an embodiment of an identification engine.

FIG. 4 illustrates an embodiment of a bit print generator.

FIG. 5 illustrates an embodiment of a bit print linker.

FIG. 6 illustrates an embodiment of a process for creating a bit printfrom a file.

FIG. 7 illustrates an embodiment of a cataloging engine.

FIG. 8 illustrates an embodiment of a link parser.

FIG. 9 illustrates another embodiment of a link parser.

FIG. 10 illustrates an embodiment of a process for cataloging bitprints.

FIG. 11 illustrates an embodiment of a process for accessing bit printsand links from a catalog.

FIG. 12 illustrates an embodiment of an arbitration engine.

FIG. 13 illustrates an embodiment of a process of determining the rightsand usage of a content file.

FIG. 14 illustrates an embodiment of a process for offering for sale apre-designated right in a content file.

FIG. 15 illustrates another embodiment of a process for offering forsale a pre-designated right in a content file.

DETAILED DESCRIPTION OF THE INVENTION

The following description of various embodiments is merely exemplary innature and is in no way intended to limit the invention, itsapplication, or uses. While various embodiments have been described forpurposes of this specification, various changes and modifications may bemade which will readily suggest themselves to those skilled in the artand which are encompassed in the spirit of the invention both disclosedherein and as defined in the appended claims.

Systems and methods have been developed for monitoring and moderatingfiles on a network. The systems and methods may provide the ability fora publisher of a file to review the uses and users of the file on anetwork and the ability for a publisher to negotiate and sell rights inthe file. The systems and methods may provide the ability to a user toresearch who owns a file and whether rights in the file are for sale.For example, the systems and methods may provide the ability to a userto request to buy rights in the file, even if there is not presently anoffer to sell the rights.

FIG. 1 illustrates a system 100 for monitoring and moderating files overa network. The system 100 includes a digital marketplace 118, processors103, servers 130, 150 and 156, each at least with some degree ofinterconnection to the Internet 104.

In one embodiment, a user utilizes a processor 103, such as personalcomputer (PC), web enabled cellular telephone, personal digitalassistant (PDA) or the like, coupled to the Internet 104 by any one of anumber of known manners. Furthermore, each processor 103 preferablyincludes an Internet browser (not shown), such as that offered byMicrosoft Corporation under the trade name INTERNET EXPLORER, or thatoffered by Netscape Corp. under the trade name NETSCAPE NAVIGATOR, orthe software or hardware equivalent of the aforementioned componentsthat enable networked intercommunication between users and serviceproviders and/or among users. Each processor also includes a mediaengine 106 that, among other functions to be further described, providesthe ability to convert information or data into a perceptible form andto manage media related information or data so that user may personalizetheir experience with various media. Media engine 106 may beincorporated into processor 103 by a vendor of processor 103, orobtained as a separate component from a media engine provider or in someother art recognized manner. As will be further described below, it iscontemplated that media engine 106 may be a software application, or asoftware/firmware combination, or a software/firmware/hardwarecombination, as a matter of design choice, that serves as a centralmedia manager for a user and facilitates the management of all manner ofmedia files and services that the user might wish to access eitherthrough a computer or a personal portable device or through networkdevices available at various locations via a network.

Processor 103 also may include storage of local media files 154 and/orother plug-in programs that are run through or interact with the mediaengine 106. Processor 103 also may be connectable to one or more devices114 such as a compact disc player and/or other external media fileplayer, commonly referred to as an MP3 player, such as the type soldunder the trade name iPod by Apple Computer, Inc., that is used toportably store and play media files.

Additionally, processor 103 may contain Digital Rights Management (DRM)software 105 that protects the copyrights and other intellectualproperty rights of the user's media files by enabling securedistribution and/or preventing or hampering illegal distribution of themedia files. In one embodiment, DRM 105 encrypts or decrypts the mediafiles for controlled access by authorized users, or alternatively formarking the content with a digital watermark or similar marking so thatthe content can not be freely distributed. Media engine 106 preferablyuses the DRM information to ensure that the media files beingexperienced through media engine 106 are not copied to or shared withusers that are unauthorized to listen to or view the content. In oneembodiment, server 150 may also use its own DRM software 155 to protectmedia files. In another embodiment, the DRM software 105 is compatible(or of the same type/format) as the DRM software 155. In yet anotherembodiment, the DRM software 105 is incompatible (e.g., a differenttype/format) with the DRM software 155.

The processor 103 may include software necessary to subscribe topodcasts. In the embodiment shown, the processor 103 includes asubscription file 160, such as an Outline Processor Markup Language(OPML) file. The subscription file 160 maintains information thatidentifies what podcasts the user has subscribed to. The subscriptionfile 160 may include a list of feeds and the feed locations.

In one embodiment, the processor 103 also includes publicationinformation 162. In one embodiment, publication information 162 includeinformation that user wishes to apply to content files that the userintends to publish. In one embodiment, the user may wish to publish ormake available content (e.g., offer for sale rights in content files) ona limited basis, such as through making available low-resolutionversions of images or movies. In another embodiment, the user may wishto publish every file located in a particular location immediately undera set of default terms (e.g., rights available, prices for certainrights, length of license terms).

In one embodiment, the digital marketplace 118 may include informationabout a user's devices 114. The information allows the digitalmarketplace 118 to identify the device and differentiate it from theprocessor 103. Furthermore, it is anticipated that a single user mayhave multiple different processors 103 and each processor 103 may beassociated with different information. For example, a user may subscribeto a news podcast on a mobile device such as a smart phone 103 orsimilar Internet connected mobile device 103 and may own rights to acontent file for use on a home computer 103. In one embodiment, thedigital marketplace 118 contains all this information. In oneembodiment, the digital marketplace 118 may include the same informationcontained in the processor's subscription file 160 for each processor103 associated with the user. In another embodiment, the digitalmarketplace 118 may include one or more files in the OPML file formatfor each user.

In one embodiment of the present invention, similar to the DRM software105 located on the user's processor 103, the digital marketplace 118 maymaintain its own DRM software 158 which tracks the digital rights ofmedia files located either in the content file database 120 or stored ona user's processor. Thus, for example, before the digital marketplace118 streams or serves up or transfers any media files to a user, itvalidates the rights designation of that particular piece of media andonly serves, streams, or transfers the file if the user has theappropriate rights.

In one embodiment, the system 100 includes a number of servers 150 thatcontain content files. That is, the servers 150 include media files 154so that they can be retrieved by a subscription manager on a processor103. In one embodiment, the server 150 includes content descriptions forthe media files 154 stored on the server. In another embodiment, theserver 150 includes content descriptions for media files 154 stored onother servers (e.g., 130, 156). In one embodiment, the server 150includes its own DRM software 155, as described further herein.

As illustrated in FIG. 1, each user's processor 103, the digitalmarketplace 118 and servers 150, as well as the other servers 130, 156are communicatively connected via the Internet 104. In alternateembodiments, different components of the system may be communicativelycoupled differently, for example each may be coupled directly to eachother wirelessly or by a local or wide area network (WAN) or the like.Additionally, functional components can be distributed so that certainfunctions of media engine may be performed at the digital marketplace118, or vice versa, or distributed in modular fashion for operation atvarious locations throughout the system 100. Thus, the descriptionherein of a function or component being associated with a particulardevice or component or location is merely exemplary.

In the embodiment shown, the digital marketplace 118 is represented by asingle system that comprises an identification engine 174, a catalogingengine 172, an arbitration engine 184, a community server 170, a filedatabase 120, and a crawler 180. In other embodiments, the digitalmarketplace 118 may comprise other elements and may be distributedacross multiple servers or other entities. For example, many methods areknown in the art for distributing functionalities across entitiesconnected, for example by networks such as the Internet.

In one embodiment, the community server 170 utilizes information andservices from the cataloging engine 172, the identification engine 174,the arbitration engine 184, the file database 120, and the crawler 180to interact with a user.

In one embodiment, the identification engine 174 creates a uniqueidentifier (e.g., bit print, digital fingerprint, digital watermark) ofevery content file either publicly or privately available. Theidentification engine may encounter or receive files in a number ofways. For example, a user may upload the file to the digitalmarketplace. As another example, a file locating engine (e.g., a crawler180) may automatically search via an algorithm or pseudo randomly, orotherwise “crawl” a public network such as the Internet. Crawling by afile-locating engine, for example, may be any type of process ofautomatically traversing a network and scanning for files. For example,crawling may be a step-wise indexing of websites. Alternatively, a filelocating engine (crawler) may focus its search on commonly-used siteswhere files are uploaded, perceived and/or downloaded. Theidentification engine may create a unique identifier for the contentfile encountered/received. The identification engine will be describedfurther herein.

In one embodiment, the cataloging engine 172 catalogs unique identifiersrelating to the files identified by the identification engine 174. Eachfile may be for sale, free for distribution or use, or otherwise mayhave its rights determined by the publisher (and/or creator) of thefile. In one embodiment, the cataloging engine 172 maintains and storesinformation relating to the files identified by the identificationengine. For example, the information handled by the cataloging engine172 may include a file's unique identifier(s) (e.g., bit print(s)),rights available in the file, and usage statistics of the file. Thecataloging engine 172 amasses information relating to files encounteredwhich can be used to cross-reference attributes of files previouslyidentified by the identification engine, such as usage versus rightsallocated, parties using the file versus parties authorized to use afile, and derivative works created using the file. The cataloging enginewill be described further herein.

In one embodiment, the arbitration engine 184 provides a clearinghousefor the rights relating to content files by arbitrating conflicts ofrights, or rights disputes, based on the catalog of unique identifierswithin the digital marketplace. In one embodiment, the arbitrationengine 184 receives requests for cross-referencing rights and resolvesconflicts relating to rights to use a file and its actual usage. Thearbitration engine will be described further herein.

The community server 170 provides an interface for the digitalmarketplace 118 to the user (and/or publisher) and may receive andinterpret requests from a user, such as “I would like to put this imageon my website.” The digital marketplace may interpret these requests as,for example, a request for the identification engine 174 to identify theimage file 154, a request for the cataloging engine 172 to locate allrelated files 154 to the image file, and a request for the arbitrationengine 184 to report the presently available rights for those filesassociated with the image file. The community server 170 may thentranslate each report or result from each of these requests into amessage for the user, such as “the image file you requested is availablefor license for $X/month.” The community server 170 may also allow apublisher of the image file 154, or files associated with it, to viewreports on the usage and licensing fees of the file or requests for thefile received by the digital marketplace.

In one embodiment, the digital marketplace 118 includes a crawler 180and a file database 120. In one embodiment, the crawler 180 searches foravailable or accessible files 154, or “crawls,” public and privatenetworks, such as the Internet 104. In one embodiment, the crawler 180may return network links (e.g., hyperlinks) to files 154, or may returnthe files themselves to the digital marketplace 118. In one embodimentthe crawler 180 crawls networks randomly. In another embodiment, thecrawler 180 crawls networks based on ratings or meta-graphic datarelated to content files 154 known to the digital marketplace 118. Inanother embodiment, the crawler 180 crawls a network according to analgorithm. For example, the algorithm may be developed for that networkor developed for finding a particular type of file.

In one embodiment, the digital marketplace 118 may store files in thefile database 120. For example, files 154 stored in the file database120 may be files found by the crawler 180, may be files created by thedigital marketplace 118 (e.g., by a user through the community server,or by any other process that creates files or versions of files asdescribed herein), or may be files submitted by the user. In anotherembodiment, the digital marketplace 118 may encounter (e.g., becomeaware of, obtain a copy of) a file 154, with or without the publisher'sknowledge or permission.

In one embodiment, the crawler 180 may find content files 154 used(e.g., displayed, distributed) on a public network, yet the crawler 180may not know to whom the content file belongs. In one embodiment, thecrawler 180 may report to the cataloging engine 172, the identificationengine 174, and the arbitration engine 184 that it has encountered thecontent file 154.

In one embodiment, files 154 encountered while crawling are processedand/or stored by the digital marketplace 118 in a manner similar tofiles submitted by users/publishers. In one embodiment, the rightsassociated or stored with a file 154 may differ depending on whetherthat file was encountered through crawling or through submission by aputative publisher. In another embodiment, the circumstances in whichthe file 154 was encountered may also be associated or stored with therights. For example, such circumstances when the file was encounteredmay include, whether the file 154 was under Creative Commons license,what entity was hosting the content file, how the content file wasdisplayed, and what, if any, digital rights management (DRM) measureswere included with the file.

As used herein, the term unique identifier includes anything used toidentify a file. In one embodiment, a unique identifier is unique inthat no other file may have the same unique identifier. For example, aunique identifier may include the time the file was processed by a partof the digital marketplace as well as information contained in the file,thereby making each unique identifier strictly unique. In anotherembodiment, a unique identifier is not strictly unique. For example, aunique identifier may be a bit print which is based on the content of afile as it would be perceived by a user, thereby allowing another fileto have the same unique identifier if the other file has a sufficientlysimilar perception of its content.

In another embodiment, a unique identifier contains a bit print forcomparison purposes and a strictly unique element (e.g., a time stamp)for identification and tracking purposes. The addition of a strictlyunique element will be understood by those with skill in the art, and,wherever bit prints are discussed herein, it should be understood that abit print may be a part of a unique identifier.

As used herein the term bit print can be any format of information thathelps to identify a file. For example, in an embodiment a bit print maybe as simple as a file name or a URL of a file. Alternatively, a bitprint may be a very complicated mathematical or formulaic representationof the data in the file. The bit print may be unique to the file, or maybe shared by other similar files, depending on the architecture usingthe bit print. A bit print may include information from metadata that isattached to or part of the content file. An example of metadata is ID3tagging for MP3 files. In one embodiment, the metadata may used in thecreation of a bit print. In another embodiment, a bit print is createdfrom the perceptible information in the content file. In anotherembodiment, a bit print is created from a combination of the perceptibleinformation in the content file and the metadata of the content file.

The processes of bit print generation may use techniques known to thosewith skill in the art to create bit prints from content files such ascorrelation with a “master” content file, fuzzy logic, artificialintelligence, neural networks, point matching, and triangulation.Indeed, a bit print may include information derived from the file in anymanner, including, but not limited to, convolution of the file,transformation of the file (e.g., Laplace, Fourier, Wavelet),integration of the file, or any other derivative information from thefile. In addition, any of these techniques can be combined withidentifications comprised in metadata associated with the content fileto aid in the creation of the bit print.

As will be appreciated, the information of the file may be perceived ina significantly different than the format in which the information iscontained in the file. For example, a .JPG file (or another formatassociated with the Joint Photographic Experts Group) may be perceivedas a photograph of a puppy when viewed through an appropriate viewer.However, the same file is stored as a string of bits (digitally) eachrepresenting a value or attribute that is part of that image file. Thesame file may also be viewed by a text editor and another view of the.JPG file may appear. The bit print may represent any of these types ofviews of the file, other types of views of the file or a combination.

As used herein, the term content may refer to any file or informationcapable of digital expression. For example, a motion picture may berepresented by a file comprising digital information that, wheninterpreted by a program or content player, may be perceived by a user.In this example, the term content may represent the motion picture asperceived, the file comprising the digital information, or the digitalinformation itself. In this example, a differently formatted copy of themotion picture may comprise entirely different information and may bereferred to as different content. However, it should be understood thatthe perception of these two motion pictures may be similar and therights associated with the two pieces of content may be the same rights(and/or owned by the same owner).

As used herein, the term “right” may refer to any right relating to howa media/content file may be used or accessed, such as access rights(including rights to access a file in the first instance), copyrightrights (e.g., display, copy, perform, prepare derivative works), rightsmade by contract (e.g., a contractual right to use a file for a limitedpurpose, a software license), trademark rights, common law rights, andpatent rights.

As used herein the term “right”, by itself, should be understood asreferring to a classification of a type of right rather than a specificpiece of intellectual property in a specific file. For example, apublisher of two files may own the same right in those two files even ifthe two files are substantially different files. For example, the rightowned by such a publisher may be the full bundle of rights afforded tothe creators of content files under applicable copyright laws. In otherwords, the publisher may own a right in one file and may own the sameright in another different file. When the term right is used to refer toa specific piece of intellectual property, it will be clearly pointedout which piece of tangible property, e.g., a media file, to which theright pertains.

If two files are substantially similar so that they would be consideredthe similar, matched, or the same (e.g., for copyright protectionpurposes), an owner of a transferable right in one file (e.g., apublisher of the file as recognized by the digital marketplace) may sellthat right to a user who wishes to use the right with respect to anotherfile. For example, the two files may be in different locations or indifferent formats and the user wishing to purchase a right may want tokeep his copy (e.g., a local copy on his computer) rather thandownloading (or otherwise obtaining) a new copy. A user may want to keepthe file if it is very large or otherwise difficult to transfer (e.g.,installed as a program on a computer). A user may wish to keep his copybecause it is in a particular format (e.g., a digital format, a physicalformat) and the copy offered by the digital marketplace is a differentformat.

If a particular right is non-exclusive in nature, the publisher of afile who owns the exclusive right from which the non-exclusive right isderived may sell many copies of the non-exclusive right to many parties.It should be understood that the owner of an exclusive right may ownmany non-exclusive rights as part of the exclusive right. For example,music files may have many non-exclusive licenses sold in them. Asanother example, the right to use an image file to print the image onetime onto a tangible object, such as paper, a garment, or a canvas, maybe sold multiple times to many different users. Rights may expire, beextinguished or be used. For example, a right to print an image file orto listen to a music file may be limited to one such printing orlistening, and may be extinguished after the use of the right.

If a right is exclusive, the publisher of a file who owns the exclusiveright in a file may sell the entirety of the exclusive right in the fileonly once. For example, a particular right to attend a sporting event(e.g., as represented by a file) may be sold only once. The digitalmarketplace, as described herein, may track any sales of rights in filesfor various purposes, including monitoring which users have rightspurchased through the digital marketplace and monitoring the rightsavailable for sale for various files.

A right embodied in tangible (e.g., non-electronic) form may beconverted into a right embodied in an electronic form, as known to thosewith skill in the art. For example, a ticket (i.e., a license right) foran event or for travel may be converted to electronic form. Theelectronic embodiment of a right (e.g., a file) may have a non-exclusiveor exclusive nature.

In one embodiment, the digital marketplace protects, monitors, andcontrols the exclusive nature of the exclusive rights. In anotherembodiment, the exclusive nature of the exclusive rights is protected,monitored and controlled by another party. There may be other means ofenforcing exclusive rights, such as through a control mechanism when theright is used. For example, a piece of DRM software may contact a serverwhen a file is activated. As another example, a barcode on a ticket maybe scanned and counted by a computer when the ticket is used, such asupon entrance to an event.

A right such as a right to perceive a known content file may carry withit the same right in the unknown file. For example, the right toperceive the known file may be given to a user, and that right may allowthe user to perceive the unknown file. For example, a user may buy aright to use a content file he already owns, such as a video file,through acquiring a right to use another content file of the same video.

A right in a known content file may not carry with it the same right inthe unknown file. For example, an owner of a right in the known contentfile (e.g., a publisher) may not want a particular version of the knowncontent file to be used or distributed, such as a distorted orreformatted version. The selling of a right in the known content filemay be a selling of the right only in that version of the content file,such as a master copy. The master copy may be specially formatted by theowner, such as a version containing DRM protection, containingadvertisements, or edited a certain way. The unknown content file whichwas matched to the known content file may be cataloged as a relatedfile. Such a related content file may also be cataloged or designated asa content file which is in an unauthorized version.

As used herein, the term publisher may refer to a user who asserts amarketed or marketable right in a piece of content (e.g., a contentfile). A user may refer to any person or entity recognized by thedigital marketplace. Therefore, publishers are users (and may bereferred to simply as users, even though they also assert rights in apiece of content), but users are not necessarily publishers.Furthermore, a user may be a publisher with respect to rights in one ormore files, but may only be a user with respect to other rights and/orother files.

Publishers may be offered options by the digital marketplace forpromoting or presenting the content in which the publisher has rights.Publishers can set up defaults for sale and presentation includingrights available, prices, and presentation format (e.g., sizes, samples,the inclusion in other presentations of the digital marketplace, theinclusion in search results within the digital marketplace). Thepublisher can control each presentation separately (i.e. control whethera free sample is given, what is required to get next sample). Thedigital marketplace can allow the publisher to control any of the modesof presentation, sale or negotiation of the rights of the content ownedby the publisher, and assert such control through setting up defaultsand/or schemas for the digital marketplace to automatically apply to thecontent rights, through individual custom control for each right ownedby the publisher, or through a combination of default and customcontrol.

FIG. 2 illustrates an embodiment of a system 200 implementing a digitalmarketplace. The system 200 includes computing devices 210, mediaservers 206 interconnected with a community server 202 via the Internet104. The community server 202 includes an interface engine 214, a userinformation database 232, a catalog database 244, a search engine 226, ameta-graphics database 242, a ratings database 240, a subscriptionengine 236, a pricing engine 234, a brokering engine 230, and areformatting engine 220. The reformatting engine 220 includes anadvertisement inserter 222 and a DRM engine 224. The community server202 provides a communicative interface between users and the digitalmarketplace. In one embodiment, the community server 202 provides aclearinghouse for rights in content files. In another embodiment, thecommunity server 202 provides statistics about the usage of contentfiles. In yet another embodiment, the community server 202 providesusers with the ability to search for a content file based on, amongother things, a file with similar content, metadata associated with thecontent file, and perceptible attributes of the content file.

In one embodiment, the digital marketplace 200 may create bit prints forelements of a file, and those bit prints may be associated with otherbit prints in order to locate uses of those elements in other works. Forexample, content files may be used to create derivative works or“remixes” of those content files. The digital marketplace and elementstherein may search that content file, which may have a new bit printitself, for bit prints of elements used from other content files.Therefore, a file may have a bit print associated with it that is new tothe digital marketplace, but there may be identified within the fileseveral bit prints that are known already to the digital marketplace. Inone embodiment, these known bit prints may have various rights owned byvarious other parties. For example, a pop song may be encountered by thedigital marketplace that has “samples” or parts of other songs in it.The digital marketplace may identify these parts of the other songs bytheir bit prints and notify parties having rights in the pop song and inthe parts of the other songs.

In one embodiment, the interface engine 214 is in communication with theidentification engine, the cataloging engine, and the arbitrationengine. The interface engine 214 may provide a user access to a catalogdatabase 244 containing, for example, a database of content files, aswell as a history of ownership of the content files, the usages of thecontent files, and the availability of rights in the content files.

In one embodiment, the user information database 232 provides theinterface engine 214 with information about a user to enhance the user'sexperience with the community server 202. In one embodiment, the userinformation database 232 may retrieve past searches performed by theuser to help tailor the user's searches on subsequent visits. Forexample, if a user has searched in the past for rock and roll songs, andpresently is searching for digital rights relating to attending aconcert, the user information database 232 may provide the userinterface with information that allows the user interface to tailor thatsearch toward rock and roll concerts. In another embodiment, the userinformation database 232 may cross-reference a user's search historywith the searching histories of other users to create recommendationsfor the user.

In one embodiment, the community server 202 may include a ratingsdatabase 240 relating to content files accessed by users through thecommunity server. In one embodiment, the community server 202 mayactively solicit ratings from users. In another embodiment, ratings maybe collected for the ratings database 240 through interpretation of auser's actions. For example, if a user searches or accesses contentfiles through the community server, the community server 202 may keep alog file of the user's access. In one embodiment, the community server202 may analyze the log file in order to obtain ratings of the contentfiles searched for and/or accessed by the user. For example, the ratingin a content file may be affected if a user searches for or buys rightsin that content file. In another embodiment, when a user's searchresults include a content file and that same user purchases a number ofsimilar content files, the rating for that content files may beaffected.

In one embodiment, the community server 202 includes a meta-graphicsdatabase 242. The term “meta-graphics,” as used herein, is related tothe term demographics, however, instead of relating to attributes suchas gender and age, the term meta-graphics relates to informationsurrounding content files and users in the digital marketplace, such assearch histories, ratings, and usage characteristics. For example, aparticular type of file may be popular with users of the communityserver who often search for content files relating to online gaming. Thecontent files that might appeal to this meta-graphic of user mightinclude podcasts relating to gaming hardware, digital assets for games(e.g., gold or swords for online role-playing games), and updates forgaming software. In one embodiment, meta-graphics stored in themeta-graphics database 242 may include all data deemed statisticallyrelated to the metadata of content files. In another embodiment, themeta-graphic data stored in the meta-graphic database 242 is related touser information stored (e.g., user metadata, search histories,publisher profiles) in the user information database 232.

In one embodiment, the community server 202 comprises a search engine226. The search engine may use information from the interface engine214, the user information database 232, and other databases in thecommunity server 202 to perform a search for content files. In oneembodiment, the search engine 226 searches a network, such as theInternet. In another embodiment, the search engine 226 searchesdatabases within the digital marketplace. In one embodiment, the searchengine 226 provides searching based on text associated with contentfile. In another embodiment, the search engine 226 provides searchingbased on information related to the content files. In yet anotherembodiment, the search engine 226 provides searching based onmeta-graphics relating to users and content files. In one embodiment,the criteria that may be included in a search for content files mayinclude, rights available in content files, classifications of thosecontent files (such as type of content, ratings of content, orpopularity of content), recommendations of the content files by otherusers, and popularity of the content files based on meta-graphicsrelated to the content files or users who accessed the content files.For example, a search may be performed by a user for the most popularpuppy photos available. In this example, the search may also be refinedby the availability of rights, such as an exclusive right to publish.

In one embodiment, the search engine 226 uses meta-graphic data or userinformation to tailor searches. In one embodiment, the search engine mayfilter content file results based on information about the user known tothe digital marketplace (for example, the community server 202),information such as search histories from the user, ratings data givenby the user, rights purchased by the user, and published content filesfrom the user. In another embodiment, the search engine 226 may tailor asearch based on availability of rights, prices of those rights orsponsored (or otherwise subsidized e.g., through advertisements)availability of rights. In yet another embodiment, the search engine 226may tailor a search based on the time of day of the search or othernetwork conditions. In one embodiment, the search engine 226 may makeknown to a user the ways in which a search is tailored. In anotherembodiment, the search engine 226 may keep hidden from a user the waysin which a search is tailored.

In another embodiment, the search engine 226 is able to receive acontent file or a link to a content file provided by a user. In oneembodiment, the search engine 226 utilizes the cataloging engine and thearbitration engine in order to perform its search based on similarcontent to a content file received from a user. In performing a similarcontent-based search, in one embodiment, the search engine 226 may sendrequests to the identification engine, the arbitration engine, and thecataloging engine. In one embodiment, the identification engine, thearbitration engine, and the cataloging engine assign at least one bitprint to the content file submitted by the user, catalog and link thebit print(s) and determine ownership of the rights in the bit print(s).In another embodiment, the cataloging engine reports similar file(s)and/or bit print(s) to the search engine 226. In yet another embodiment,the arbitration engine reports ownership of the rights in the similarfile(s) to the search engine 226.

In one embodiment, the search engine 226 receives results from theserequests, and provides the user in with a group of results that mayinclude similar content files. In another embodiment, the search engine226 allows the user to refine his search and search again by selectingcontent files from these search results (e.g., that match the contentfile and/or the rights the user is seeking).

As one example, a user may wish to see if the particular picture has anyrights that are available for sale, or if anyone owns rights in aparticular picture. To initiate a search, the user presents the pictureto the search engine 226, along with parameters for the search (e.g., arequest to find rights that are available and/or if those rights are forsale.). Then the search engine 226 forwards the file and a request tothe identification engine which produces at least one bit print for thefile. The bit print or bit prints are then forwarded to the catalogingengine which determines all the related bit prints. The group of arelated bit prints is then forwarded to the arbitration engine whichdetermines the relationships between the bit prints in the rightsavailable in the bit prints. The arbitration engine then returns the bitprints and rights available in the bit prints to the community server202 and the search engine 226. In one embodiment, the search engine 226at this point may request copies (e.g., full copies, formatted versions,“thumbnails”) of each content file represented by the bit prints fromthe cataloging engine and/or the file database. In another embodiment,the search engine may also retrieve copies from the Internet.

The search engine 226 may present, through the community server 202, theresults to the user. In one embodiment, if the user is satisfied withthe search results the user may stop the search process. In anotherembodiment, if the user would like to perform further searching the userselects one or more of the search results and asks the search engine 226to continue searching. In one embodiment, the user may have provided animage that was close to but not exactly the image for which the user wassearching. Therefore, a user may wish to use the search engine throughseveral iterations the user may need to use the search engine throughseveral iterations before finding the results desire finding the desiredresults.

In one embodiment, a user may mix or aggregate content in a compilationor “remix.” This compilation (which should be understood both in thecopyright and non-copyright senses of the word) may be governed byrights of the user and rights of the publisher(s) of the content fromwhich it is composed. The user may have obtained the content for thecompilation by interfacing with the community server 202, by retrievingfiles from another source, or by creating the content himself. When thedigital marketplace encounters this compilation, the digital marketplacemay send a request to the identification engine to create one or morebit prints for the compilation, send a request to the cataloging engineto catalog the bit prints, and send a request to the arbitration engineto determine the ownership of the rights to the content in thecompilation.

In one embodiment, the community server 202 includes a subscriptionengine 236. The subscription engine 236 provides users with access tocontent file on a subscription basis (e.g., paying for a month ofunlimited access to a group of content files). The subscription engine236 may access the ratings database 240 and the meta-graphics database242 to determine content files to include in subscriptions. In oneembodiment, the subscription engine 236 selects a group of content filesthat it deems “head content” and the subscription engine includes thegroup of content files initially in a subscription grouping. In anotherembodiment, the subscription engine 236 adds content files that thesubscription engine deems “tail content” to the subscription grouping.“Head content” refers to popular content with a large audience andpresumably high demand, whereas “tail content” refers to content which,while possibly able to be sold, is in low demand. In one embodiment, thesubscription engine 236 includes the tail content based on informationabout the tail content contained in the ratings database 240 and/or themeta-graphics database 242. In one embodiment, tail content may beincluded by the subscription engine 236 based on a popularity rank inthe ratings database 240 and/or the meta-graphics database 242. Inanother embodiment, tail content may be included by the subscriptionengine 236 based on a particular correlation between the tail contentand the head content contained in the subscription grouping. Forexample, if the particular item of tail content is reviewed very highlyby users who are subscribers to the subscription, the subscriptionengine may include that piece of tail content or similar pieces of tailcontent in the subscription.

In one embodiment, the community server 202 includes a pricing engine234. The pricing engine 234 provides guidance to a user on prices forrights in content files. In one embodiment, the pricing engine 234provides a user with suggestions of prices, or a range of prices (e.g.,pricing buckets) to charge for rights that the user wishes to sell orlicense in a content file. In another embodiment, the pricing engine 234provides a user with prices or a range of prices for rights that theuser wants to acquire in a content file. In yet another embodiment, thepricing engine 234 provides negotiation support between users innegotiating a price for rights in a content file.

In one embodiment, the pricing engine 234 may include results fromprevious sales of rights in similar content files as determined bycommunicating with the cataloging engine to determine what constitutes asimilar file, and the brokering engine 230 to determine recent prices.In another embodiment, the pricing engine 234 may interface with thecommunity server 202 to determine a “live auction” price from otherusers. In yet another embodiment, the live auction may be performed withusers who determine prices for content files but are not interested inpurchasing rights in the particular content file for which pricingguidance is sought from the pricing engine 234 by a user. In yet anotherembodiment, the pricing engine 234 may include publishing informationrelating to the user requesting pricing guidance from the pricingengine. For example, the user's default prices may be considered by thepricing engine 234 so as not to provide guidance that is too differentthan what that user believes rights in his content file are worth. Inone embodiment, the pricing engine 234 may also accept information aboutthe cost of producing the content file in providing pricing guidance. Inanother embodiment, the pricing engine 234 may include networkconditions (e.g., demand, the time of day) and prevalent pricingstructures (including comparable files, and comparable content filegroupings) known to the digital marketplace in the pricing guidance thepricing engine provides a user. In yet another embodiment, the pricingengine 234 may take into account the history of success and/or ratingsreceived on previous content files from the same publisher in providingpricing guidance.

In one embodiment, the community server 202 includes a brokering engine230. The brokering engine 230 moderates negotiations between users indetermining and transferring rights in content files. The brokeringengine 230 may receive information from the arbitration engine relatingto rights owned in content files according to information known to thedigital marketplace. The brokering engine 230 may obtain new informationrelating to the ownership of rights in a content file and may combine itwith the information previously known to the digital marketplace. Forexample, a user may provide the brokering engine 230 with proof that hecreated a particular content file which the brokering engine 230 maythen store. The brokering engine 230 may also be able to contact a userwho has previously expressed interest in purchasing rights in a contentfile, and offer rights to that content file. The brokering engine 230may submit information about the content file to the arbitration engineand/or the cataloging engine and may request information about thecontent file. In order to generate a price, the brokering engine 230 mayrequest information from both the ratings database 240 and themeta-graphics database 242, such as information relating to similarfiles to the content file being brokered. The brokering engine 230 mayalso receive pricing guidance from the pricing engine.

In one embodiment, the community server 202 includes an accountingengine 246. The accounting engine 246 keeps track of licenses,royalties, usages, and violations of rights in content files. In oneembodiment, the accounting engine 246 communicates with the catalogingengine and the arbitration engine to determine usages of content fileson a public network, such as the Internet. The accounting engine 246 maymonitor usage of a particular content file in order to calculateroyalties due to a publisher based on a license of that content file. Inanother embodiment, the accounting engine 246 may become aware ofviolations of licenses, or other unlicensed uses a content file. In oneembodiment, the accounting engine 246 may contact a publisher (e.g., auser who owns rights in the content file) to report uses of the contentfile encountered by the digital marketplace. For example, the accountingengine 246 may notify publishers that a content file in which they ownrights is being misused. In another embodiment, the accounting engine246 may collect royalties for the licensed use of a content file, notifythe publisher of the extent of the use of the content file, and depositthe royalties into the publisher's account. In this manner, thecommunity server may provide a “turn-key” service for monitoring use ofa content file under a license and collecting royalties for that use onbehalf of a publisher.

In one embodiment, the accounting engine 246 provides a licensingclearinghouse for a user interested in licensing multiple content filesor rights to use the multiple content files. In another embodiment, theaccounting engine 246 provides the clearinghouse functionality byinterfacing with the cataloging engine to determine all the bit printsnecessary for licensing (e.g., all of the bit prints related to the bitprint(s) of the content file desired), and interfaces with thearbitration engine to determine the owners of rights in those contentfiles (and/or bit prints). Therefore, a user interested in obtainingrights to one or more content files, after that user has determinedwhich content file he is interested in, and brokered transactions withthe publishers (e.g., rights owners) to those content file may set up aturn-key solution with the accounting engine 246.

As one example, a user wishing to secure rights to create a derivativework, such as a re-edited version of a popular TV show may broker a dealfor those rights with the brokering engine 230. The user may thenrequest the accounting engine 246 to implement that deal. For example, auser, under the terms of the license, may sell “per view” uses of thatre-edited show and may use the accounting engine 246 to distributeroyalties to all the rights owners in the re-edited show. The accountingengine 246 would then monitor the use of the re-edited show (e.g., thesales of “per view” uses), and calculate the royalties due. Theaccounting engine 246 then deducts from the user's account thoseroyalties, and sends payments to all the rights owners of the contentused in the re-edited show.

In one embodiment, the community server 202 includes a repackagingengine 220. The repackaging engine 220 creates copies of content filesformatted for users and/or for specific purposes. In one embodiment, therepackaging engine 220 includes an advertisement inserter 222 and adigital rights management (DRM) engine 224. In one embodiment, therepackaging engine 220 provides users who have purchased rights in acontent file the ability to access those rights regardless of theplatform in which the user wants to access those rights. For example, auser may wish to view a video on his computer, and may request therepackaging engine 220 to format the video for viewing on his computer.However, that same user may wish at a later time to view the same movieon a handheld digital media player. At that time the user may ask therepackaging engine 220 to repackage the movie and/or provide him with acopy of the movie appropriate for playing in a handheld media player. Inanother embodiment, the repackaging engine 220 provides a user anopportunity to receive another copy of the content file, after the userhas lost the content file, for example, as a result of a hard drivecrash. In one embodiment, the repackaging engine 220 is in communicationwith entities such as the brokering engine 230, the accounting engine246, the cataloging engine, and/or the arbitration engine in order todetermine whether a request by a user to receive a file again complieswith the rights owned by that user in that file. For example, a user mayonly own rights in a particular file for use with a particular piece ofhardware. In another example, a user may own rights in a file only forone time use.

In one embodiment, the repackaging engine 220 includes an advertisementinserter 222. The advertisement inserter 222 may repackage a contentfile to include advertisements. In one embodiment, the advertisementinserter 222 includes advertisements in a content file based oninformation from the brokering engine 230 about a negotiation between auser and a publisher. In another embodiment, a user may agree to receiverights in a content file (e.g., rights to view the content file) underthe condition that the content file will include advertisements. In oneembodiment, as consideration for viewing the content file including theadvertisements, the publisher agrees to receive a lower price for therights in the content file from the user. In another embodiment, thebrokering engine 230 also negotiates with a publisher of theadvertisements, and secures payment from that publisher based on theadvertisements included in the content file, and presumably viewed bythe user. In yet another embodiment, the accounting engine 246 collectsroyalties from the publisher of the advertisements when and if the useraccesses (e.g., views, downloads) the content file includingadvertisements. In one embodiment, the accounting engine 246 makes adeposit in the account of the publisher of the content file, the depositincluding payments from the user and the publisher of theadvertisements. In another embodiment, the repackaging engine 220 mayprovide at the request of the brokering engine 230 a content file thatis available completely royalty-free to a user based on theadvertisements contained therein.

In another embodiment, the repackaging engine 220 includes a digitalrights management (DRM) engine 224. The DRM engine 224 resolves DRMsoftware issues for users and publishers (e.g., users who own rights incontent files). In one embodiment, the DRM engine 224 creates files forusers formatted to allow access to the file in multiple DRMenvironments. For example, a user who purchases rights in a content filemay anticipate using those rights within a particular DRM environment,however, the user may wish to use the content file (e.g., view a video,listen a song, print a report) in another DRM environment. In oneembodiment, the user may contact the repackaging engine 220 and requestthat the content be repackaged to fit this new DRM environment. Inanother embodiment, based on the rights owned by the user in the contentfile, a DRM engine 224 will repackage the content file, including theDRM portion of that file and returned to the user. In one embodiment,the digital marketplace may develop and use a proprietary DRM system(which may be DRM software) in addition to DRM systems used by contentplayers. In another embodiment, the digital marketplace may use aproprietary DRM system (which may be DRM software) to control access tofiles created within the digital marketplace. In yet another embodiment,the digital marketplace integrates the proprietary DRM system (which maybe DRM software) with the identification engine's function of assigninga bit print to a content file. As used herein, the term proprietary DRMsystem should be understood to mean that the system is designed by thedigital marketplace, not necessarily that the DRM system is not used byor shared with third parties.

FIG. 3 illustrates an embodiment of an identification engine 300. Theidentification engine 300 can create a unique identifier for each fileencountered by the digital marketplace. The embodiment of theidentification engine 300 shown comprises a request transceiver 302, afile transceiver 304, a file parser 306, a file perceiver 310, a bitprint database 312, a bit print generator 314, a bit print linker 316,and a bit print transceiver 320. The embodiment of the identification300 engine shown may be distributed over a number of physically distinctsystems. The embodiment is described here as a unit but is not meant tolimit the identification engine 300 to the embodiment shown.

The request transceiver 302 receives requests for determining anidentification or bit print of a file, parts of a file, orauthentication requests. For example, a crawler may want theidentification engine 300 to determine a bit print for a file that wasfound on a network while crawling the network, or a user may wish toidentify a file of unknown origin. The request may be made for the fileto be identified so that the file may be matched to a known file, whoserights are known. The request may also be made to populate a filedatabase.

The file transceiver 304 receives files from a source that may be withinthe digital marketplace or outside of the digital marketplace. In oneembodiment, the file may be contained in a file database within thedigital marketplace (e.g., 120). In another embodiment, the file may bestored on a remotely located machine (e.g., server 130) accessible via anetwork. In yet another embodiment, the file may be stored in the filetransceiver 304. The file transceiver 304 makes available the receivedfile to the file parser 306 and the file perceiver 310.

The term file, as used herein, can be any type of file, comprising anytype of information/content, such as media, audio, .html file, .pdf of areport, access to webpage, assets (e.g., gold and swords) in a videogame, or a password stored in an ASCII format. A file may includesoftware code, (e.g., source code, compiled format) or any machinereadable instructions. The identification engine 300 can create a bitprint out of a non-digital asset or another right, which may beexpressed in electronic form, for example, the right to attend abaseball game, or an entry in a lottery or raffle. Therefore, a file mayinclude an electronic representation of a right, such as a contractright. As used herein the term “content file” should be understood ascoextensive with the term file, and the use of either term should not bemore limited than the use of the other.

The file parser 306 parses a file based on a received request. The fileparser 306 parses a file in order to prepare for bit print generationfor the file. To that end, the file parser 306 may extract data relatingto the file in order to pass that data to the bit print generator 314.For example, the file parser 306 may determine attributes of the file,including the format of the file (such as represented by an extension ofthe file e.g., jpg, .html, .pdf) and any metadata associated with thefile. In one embodiment, the file parser 306 may detect a machinereadable right (MRR) associated with the file. For example, a MRRassociated with the file may be a creative commons license limiting theuse of the file. In another embodiment, the file parser 306 may alsodetect elements within the file that may be related to known bit prints.For example, the file may have elements of other files that have bitprints (either for the other files or for those elements).

For example, a bit print may represent only a portion of a file. In oneembodiment, a bit print of a portion of a file may identify just theportion of the file. In another embodiment, a bit print of a portion ofa file may identify the entire file. For example, a particularlydistinct or identifiable section of a file (e.g., a climactic scene orthe image of an actor's face in a movie) may be used to identify theentire file. In one embodiment, a portion of the file chosen to carry abit print identifying the entire file is chosen at random. In anotherembodiment, a portion of a file is chosen based on an attribute of theportion of the file. For example, it may be necessary only to create abit print for every 30^(th) frame of a movie, or the center section of aphoto, based on type of content in the file. In one embodiment, aportion is chosen based on the size of the file.

The file perceiver 310 may create several altered formats of the file topass to the bit print generator 314 to aid in the creation of a bitprint for the file, and for any elements contained in the file. Thealtered format may be perceptible by a human, such as through viewing animage or a movie, or through listening to a music file (e.g., decodingan .MP3 file into an audio waveform). In another embodiment, the alteredformat may be a digital format which is not perceptible by a human. Forexample, the file in an original format may be in an AVI format, and thefile in the altered format may be in an MPG format. In anotherembodiment, the file in the altered format may be resized and/orre-sampled to compare it with other files. In another embodiment, thealtered format may be a format that is not perceivable through anindustry standard format, but is, however, useful to the file perceiver310. For example, the file perceiver 310 may convert a music file or animage file into a histogram, or may create a two-dimensional Fouriertransform of an image in order to compare an image to another image.

The file parser 306 and file perceiver 310, working in combination, mayprovide the bit print generator 314 with a group of files which havebeen created from the file received by the identification engine 300. Inone embodiment, the file perceiver 310 and/or file parser 306 mayseparate a content file into elements based on perceptual cues of thecontent file in order to create bit prints for the elements. Forexample, a bass line of a song may be an element for which the bit printgenerator creates a bit print separately from a drum beat. The fileperceiver 310 may aid the bit print generator in determining elementsfor which separate bit prints should be created, and may also aid thebit print generator in separating the content file into elements for thecreation of bit prints for those elements.

Any files and elements of files are then passed to the bit printgenerator 314 for creation of the bit prints related from the files andelements. The original file may be included in the group of files passedto the bit print generator 314. A generated bit print is returned by thebit print generator 314 and may be stored in the identification engine'sbit print database 312 and linked with other bit prints returned fromthe bit print generator.

The bit print linker 316 performs the linking function. In oneembodiment the bit print linker 316 only links bit prints which arebased on related files (e.g., files which were passed to the bit printgenerator as part of a group of files). In another embodiment, the bitprint linker 316 links bit prints of unrelated files. The bit printlinker and its function will be discussed further with respect to FIG.6.

FIG. 4 illustrates an embodiment of a bit print generator 400. Theembodiment of a bit print generator 400 includes a bit print transceiver402, a file transceiver 404, a resizing engine 406, a reformattingengine 410, a bit print database 412 and a bit print engine 414. Theresizing engine 406 and reformatting engine 410 may provide other filesthan the file received by the identification engine or the alteredformat files created by the file perceiver, based on the requirements ofthe bit print engine 414 and the bit print database 412. For example,the bit print engine 414 may request another file be created in adifferent format from the resizing engine 406 or the reformatting engine410. This requirement may be made by the bit print engine, for example,when it encounters a part of the bit print creation for which adifferent size or format of the file would be useful.

In the embodiment shown, the bit print generator 400 may create a bitprint based on the received file, the altered formats of the receivedfile from the file perceiver, the resizing engine 406, or thereformatting engine 410 (e.g., the received file as transformed intodifferent formats, thereby comprising a set of files each with analtered format). The bit print generator 400 may also use informationreceived from the file parser about the received file.

In one embodiment, the bit print database 412 may be used for temporarystorage of bit prints as they are created, compared, and grouped fortransmission. In another embodiment, the bit print database 412 maystore bit prints on a somewhat permanent basis for reference or otheruse in creating bit prints.

As will be appreciated, a bit print generator 400 may adapt to andaccount for the various ways in which a content file may be formatted ormanipulated without changing significantly the ability to perceive oruse the underlying information. Many rights inherent to content inure inthe perception or use of that content, not in the format of the content(i.e., the actual arrangement of bits constituting a particular file).For example, a patented process may be performed by two computersoftware programs that are entirely different because they were compiledat different times. Another example is a piece of music represented bytwo files that have different sampling rates. The different samplingrates create different files, but the underlying music is similar andprotected by the same rights. The bit print generator 400 may,therefore, adapt the process of generating the bit print to fit a typeof content file and/or to respond to a type of modification that masksthe identity of a content file, yet still violates (or allows violationof) the rights in the underlying use or perception of the content. Forexample, a bit print for a music file may use frequencies, histograms,and waveform analyses, while a bit print for an image file may usecorrelations, two dimensional Fourier transforms, resizing andrun-length coding analyses. In short, any manner of processing of thecontent file may be used by the bit print generator 400 in creating thebit print for the content file. In one embodiment, the processing may beperformed by the file perceiver, the bit print generator 400, or anycombination of the two.

Because the creation of a bit print may render different bit prints fordifferent files, even though the files are perceived in a similarfashion by a user, matching a bit print to another bit print should beconsidered an inexact process. In other words, matching a bit print toanother bit print may be done to some threshold of similarity, withmatching bit prints being considered bit prints which are matched onlyto some threshold or level of exactness.

In one embodiment, a bit print generator 400 may create many bit printsfor each content file. These bit prints may each be associated with anelement of the content file, identifying an element in the content filethat may be used (and then later identified) as an element in anothercontent file. In one embodiment, the bit prints for each element maytrack parts of the larger file, or master file, parts which may beincluded in derivative content files or “remixes” of the larger contentfile. In another embodiment, to the extent that the owner(s) of rightsin a larger content file has rights in the constituent elements of thecontent file, the bit prints for each element may help track, controland market the rights in those elements. For example, the bit printgenerator 400 may identify still images inside a movie file, and maygive each of those images its own bit print. In one embodiment, the bitprint generator 400 may also give the movie file its own bit print. Inanother embodiment, the bit print generator 400, therefore, may createseveral bit prints from one content file.

In one embodiment, the bit prints created by the bit print generator 400from the content file may include bit prints similar or equal to bitprints already known to the digital marketplace. In another embodiment,the bit prints identified for the elements of a content file may alsoinclude elements that are not known to the digital marketplace.

Bit prints may include time codes, such as codes showing when particularelements appear in a content file. For example, the bit print for acontent file may include a time code and reference for each element ofthe content file, along with a representation of the perception of thecontent file as a whole. In one embodiment, the bit print of the contentfile represents the content file as a whole as well as the ordering ofand reference to the elements comprising the content file. In anotherembodiment, the bit print for the content file may be associated vialinks to the bit prints for the elements and the links may include timecodes.

FIG. 5 illustrates an embodiment of a bit print linker 500. Theembodiment of the bit print linker 500 shown comprises a bit printtransceiver 502, a link transceiver 504, a link database 512, a bitprint database 510, and a relationship engine 506. In one embodiment,the relationship engine 506 performs a function of determining therelationship of at least two bit prints to each other, such as bycomparing the bit prints to identify similarities. In another example,the relationship engine 506 may create links between bit prints based onthe determination of the relationship between the bit prints.

As used herein, the term “link” refers to a computer-recognizabledescription of how two media files are related. As used herein, the term“relationship” refers to a hierarchy, tree, lineage, dependency,genealogy, co-ownership or other connection between bit prints and/orthe files the bit prints represent. A link may be generated from twomedia files or from bit prints representing those files. Therefore, alink may describe a relationship between two or more bit prints. In oneembodiment, one bit print is determined to match another bit print ifthere exists a link describing the two bit prints as significantlyrelated. Also, a link may describe a relationship between two or morefiles. A link may be a part of the bit print, or a part of the contentfile's metadata that describes relationships with other bit print(s).The description of bit prints herein has shown how bit prints may becontained within another bit print, and how a relationship between thebit prints may inherently be expressed through this structure. It shouldbe understood that this structure may also comprise a link because thestructure inherently describes at least one relationship between the bitprints contained in the structure. A link may be stored in a linkingdocument, a document created and stored to describe the relationshipbetween files and/or bit prints. Links or linking documents may bestored separately from bit prints, for example in a link database.

One example of how a media file might be related to another media fileis an image which appears inside another image. For example, a picturemay be hanging on a wall in the background of another picture. Thepicture on the wall therefore appears inside the larger picture. Animage may also appear inside a video (e.g., the picture on the wall maybe in several frames of the video file as the video shows a scene in theroom). A link may be created to show that there is a relationshipbetween the picture on the wall and the other file, the video file orthe other image, and the link may include the nature of therelationship, the various times when each file was presented on apublicly accessible network, and who purportedly owns each file.

Another example of how a media file an audio file may be “sampled” orotherwise used in another music file. It is common practice forcontemporary musicians to use other audio segments in their music.Therefore, a piece of music may appear in another piece of music createdby another person. A piece of music may be used in many music files,such as a very popular drum solo (e.g., the “Amen break” is commonlyused in hip-hop and dance music), and therefore there may be manyrelationships between a file and other files. A link or linking documentmay be adapted to particular situations to make the link or linkingdocument easier to search. For example, a linking document may becreated for a popular sample of music which contains all of the uses ofthe sample known to the digital marketplace. Alternatively, a linkingdocument or link may be created for each use of a sample of music, andthe linking documents or links may be stored in a searchable linkdatabase.

In one embodiment, the relationship engine 506 may determine that onebit print represents an element of a content file represented by anotherbit print. For example, the relationship engine 506 may link two bitprints describing their relationship as that of a content file and anelement contained in the content file. In one embodiment, bit printsinclude links to one another, such as a link that describes “this firstbit print is part of this second bit print” or a link that describes“this first bit print comprises this second bit print, this third bitprint, and this fourth bit print.” In one embodiment, links describe arelation of the content files (or elements of the content files) theyrepresent, and may not necessarily describe a relation between the bitprints themselves. In one embodiment, a bit print generator may passrelated bit prints to the bit print linker 500 for linking orassociation with each other. In another embodiment, the relationships orlinks between bit prints may be stored in a database such as the linkdatabase 512 in the bit print linker 500, or in another part of thedigital marketplace, such as the community server.

In one embodiment, the relationship engine 506 creates links based onbit prints from the bit print generator. In this embodiment, the bitprint generator determines associations between the bit prints andtransmits the associations to the bit print linker 500, which wouldcreate links between those bit prints and transmit those links to acataloging engine. In one embodiment, links may be stored and maintainedby the cataloging engine.

In one embodiment, the relationship engine 506 creates hierarchies ortrees of bit prints and transmits them to the cataloging engine forstorage and organization. In this embodiment, the cataloging engine mayidentify cross-references between these hierarchies or trees of bitprints and store the bit prints in any appropriate manner.

In another embodiment, a bit print may be constructed in such a mannerthat its relationship with other bit prints is contained inherently inthe bit print itself. For example, a correlation operation (such as atwo dimensional optical correlation) may contain elements that may beidentified by searching for them individually. In one embodiment, a bitprint comprises all of the bit prints of the elements within it, so thatan entity trying to find a particular element within the content fileonly needs to look at the content file's bit print to see if the elementis within the content file. An example would be a song's bit print thatcomprises a list of representations of pitches and rhythms. In thisexample, a bit print of an element of another song may include a fewpitches and their related rhythms. An entity (e.g., an arbitrationengine) trying to determine if an element exists in the song may matchthe element's bit print against parts of the song's bit print to see ifthere is a match. Other pattern matching techniques could also be usedto match bit prints as well.

In one embodiment, the bit print linker 500 and particularly therelationship engine 506 create links from these inherently-containedrelationships. These links may be stored and transmitted to a catalogingengine. The cataloging engine may then use the links to index the bitprints for search and/or retrieval. In one embodiment, a bit print thatcontains inherent relationship information or contains other bit prints(as described above) may still have a link or links created for it bythe relationship engine 506 and transmitted to the cataloging engine toaid in searching, correlation, and/or retrieval of some or all of itsrelated bit prints. In another embodiment, a larger bit which containsinherent relationship information or other bit prints may be divided bythe relationship engine into a group of bit prints, with each bit printof the group representing an element of the larger bit print.

In one embodiment, the bit print linker 500 may also designate bitprints as clones or ghosts of one another. Two similar content files mayhave the same bit print generated by the bit print generator or may havesimilar bit prints. These similar but not identical bit prints may beassociated as clones or ghosts of one another. For example, a first bitprint may be related enough to a second bit print to associate them asghosts or clones of each other. The designation or association of bitprints as clones or ghosts may also be performed by the arbitrationengine, as discussed further herein. In one embodiment, bit prints thatare clones or ghosts of each other may represent similar content files,or content files that may be perceived similarly. Thus, content filesthat are similar but are assigned different bit prints may be associatedand/or designated as having similar perceptions. In another embodiment,the clone or ghost designation may represent that there are similarrights in the content files represented by the bit prints. In oneembodiment, a bit print may be a clone or a ghost of another bit print,regardless of whether the bit print represents an entire file or anelement of a file.

In one embodiment, a bit print may be re-created or “recast” after ithas been created. The decision to re-create a bit print may be made onthe basis of a conflict of ownership or a dispute about the identity ofa content file or element within a file. In one embodiment, there-creation can also be based on human-perceived similarities betweentwo files. For example, a user might submit two files and assert thatthey are similar or derivatives of each other. In one embodiment,re-creations or re-castings may be focused only on an element of thefile. In another embodiment, the original bit print and the recast bitprint may be stored. In another embodiment, the original bit print andthe recast bit print may be associated with one another, including asghosts or clones.

FIG. 6 illustrates an embodiment of a process 600 for creating a bitprint from a file. In one embodiment, a file is located 602automatically or otherwise without a request received to create a bitprint from that file. In this embodiment, the file may be unknown to thedigital marketplace when it is located, and the process 600 of creationof a bit print may begin on the file, even though the file may be ofdubious significance to the digital marketplace at that time. In thismode, the process 600 may build an authoritative catalog of files whichare used on a publicly accessible network.

The file may be retrieved from its location where it was located 608. Inone embodiment, the file may be located 602 without simultaneouslyretrieving the file 608. For example, a file may be located 602 by nameand location alone, and the content of the file may not be retrieved 608until another time (e.g., until after a determination has been made thatthe file is pertinent to be cataloged by the digital marketplace). Inanother embodiment, the locating of the file 602 includes retrieving thefile and so retrieving the file is not required as a separate operation.Retrieving a file 608 may be performed through downloading or otherwiseaccessing the file.

In another embodiment, a request is received 604 for generating at leastone bit print from a file. In one embodiment, the file is received 606.In another embodiment, a reference to a location of the file isreceived. For example, a location of a file may be received and then thefile may be retrieved, downloaded or otherwise accessed from thatlocation.

When a file is either received 606 or retrieved 608 it may then beprocessed. In one embodiment, the file may be parsed 610 as describedherein. In another embodiment, the original file is perceived 612,rendered and/or formatted as described herein. The resulting file(s) maythen be parsed 614, also as described herein. The results of the parsing610, 614 and perceiving 612, as well as the results of the first parsingof the original file, are used to generate 616 at least one bit print.The resulting bit print(s) may be linked 620 as described above, and atleast one of the bit print(s) may be stored 622 (e.g., in a bit printdatabase). This process 600 is meant as an example of a process forperforming some of the functions described herein, and is not meant tolimit the system or methods described herein for providing a digitalmarketplace.

In one embodiment, the transformation used for bit print generation 616may be selected based on the type of content of the file, or based onhow the content of the file is perceived. For example, effectivelyidentifying and/or cataloging content which is perceivedmulti-dimensionally may require identification techniques which are alsomulti-dimensional. In one embodiment, a multi-dimensional transformation(e.g., a 2-dimensional Fourier transform) may be used to generate a bitprint 616 for a file containing multi-dimensional content, such as animage or video file. In another embodiment, a linear transformation maybe used for a file with linear content. For example, an audio file maybe perceived 612 in a linear manner such that a section of the audio maybe perceived (e.g., listened to), identified by a bit print andcataloged separately from the surrounding sections of audio. Therefore,sections of audio may be separately identified or the whole audio filemay be identified by a combination of the separately identified sectionsof the audio file.

FIG. 7 illustrates an embodiment of a cataloging engine 700. Thecataloging engine 700 comprises a bit print transceiver 702, a linktransceiver 704, a bit print database 710, a link database 712, and alink parser 706. The cataloging engine 700 may perform the function inthe digital marketplace of storing and maintaining a catalog of bitprints and links (e.g., through databases 710, 712) relating to filesencountered by the digital marketplace, for example, files that areaccessible or available on public or private networks. The catalogingengine 700 receives bit prints relating to files. In another embodiment,the cataloging engine 700 may receive bit prints and the content filesassociated with those bit prints. In one embodiment, the catalogingengine 700 catalogs the bit prints to provide the digital marketplacewith the ability to distinguish between content files that are copies(or transformations) of other content files and content files that aredistinct from other content files. For example, the cataloging engine700 may provide a means of efficiently searching and retrieving bitprints. In one embodiment, the cataloging engine 700 performs thisfunction by maintaining a bit print database 710 and a link database712.

The bit prints stored by the cataloging engine 700 and their links maybe passed to the arbitration engine in order to resolve any conflicts orto clarify any ownership or identity issues relating to the new bitprint and the bit prints known by the digital marketplace. Bit printsknown by the digital marketplace may include bit prints stored in thebit print databases of the identification engine, the cataloging engine700, the arbitration engine, or otherwise known to exist by the digitalmarketplace (e.g., in content file database).

As described above, bit prints may also include links or may havelinking information encoded into the format of the bit print. In oneembodiment, the link parser 706 examines links and linking informationto aid the organization of the bit print database 710 and the linkdatabase 712 to provide the digital marketplace the ability to referencea new bit print against bit prints known by the digital marketplace. Thenew bit print may be created from a content file encountered by thedigital marketplace or may be created from a copy or transformation of acontent file stored in the digital marketplace. There are many functionsdescribed herein which the cataloging engine 700 may provide and thelink parser 706 may be adapted to suit the functions of the catalogingengine through the link parser's various processes of examination,hashing, and parsing of links.

In one embodiment, the cataloging engine 700 receives bit print(s)relating to a content file whenever the digital marketplace encounters acontent file. The digital marketplace may encounter files under a numberof circumstances. For example, the digital marketplace may find fileswhose rights are not claimed by anyone, except, presumptively, the owneror promoter of the site where the file was found. The digitalmarketplace may also receive a file from a publisher (or putativepublisher) and may generate bit print from that file. This may be a“master” bit print if the publisher claims to have created the work.This master status may be contingent upon checking against other bitprints determined to have already have existed when the (putative)publisher submitted the file to the digital marketplace.

In one embodiment, the cataloging engine 700 may receive identificationsof content files encountered by a crawler. In one embodiment, thecataloging engine 700 may build a record for a new and/or unknowncontent file by designating a history related to that content file. Inone embodiment, the cataloging engine 700 creates a history for each bitprint, for each new bit print that is presented to the cataloging engine700. In another embodiment, the cataloging engine 700 creates and storesa history for each group or set of related bit prints. In oneembodiment, a history of a group of related bit prints (or “a familyhistory”) may include the date, the site, and other circumstances underwhich each content file was encountered. In another embodiment, thehistory stored by the cataloging engine 700 may include the date andtime the file was encountered, the location where the file wasencountered, and/or the owner of the site where the file wasencountered.

In one embodiment, the cataloging engine 700 may store bit prints forseveral different versions of a content file and may store links betweenthem based on output from the link parser 706. The cataloging engine 700may store the link information in the bit print itself or the linkdatabase as described above. In one embodiment, the digital marketplacemay automatically create these versions (note that they are each filesthemselves), bit prints for each file, and links between the files. Inanother embodiment, a publisher may create different bit prints fordifferent formats of his content file, such as for a “thumbnail” or“preview” of the content and for the full content file itself. Thepublisher may also wish to create versions with, for example:high-resolution and low-resolution; different language tracks; orsurround sound and stereo audio tracks. In another embodiment, thepublisher may want to designate versions for use with different hardwaresuch as: computer, television, or mobile phone.

In one embodiment, the cataloging engine 700 may receive bit prints andlinks for a number of reasons, including to perform catalog maintenance,to populate the catalog (e.g., a content file database, the bit printdatabase 710 and/or the link database 712), to perform a request by apublisher to establish or protect his rights in a content file, tocollect a royalty from a licensed user of a content file, and to monitorthe creation of derivative works from the content file. In oneembodiment, the cataloging engine 700 may receive bit prints and linksfrom the crawler, the identification engine, the community server (e.g.,from a user/publisher), or from the digital marketplace generally.

The cataloging engine 700 may identify a content file for inclusion bythe community server in the subscription for the user. In oneembodiment, the cataloging engine identifies a content file by metadataand ratings of the content file. In another embodiment, the catalogingengine identifies a content file by recommendations of the content file.In yet another embodiment, the cataloging engine identifies a contentfile by searches performed by the community server. In yet anotherembodiment, the cataloging engine identifies a file based on linksbetween bit prints of files.

In one embodiment, the cataloging engine 700 may store bit prints andlinks in databases in such a manner that the bit prints and links areassociated as a group or packaged content (which may be referred to as adigital package). For example, an image of an album cover may beassociated as a group or packaged content along with the music files forthat album. Another example is a movie file associated with extrascenes, out-takes, or trailers associated with the movie file as a groupor packaged content. In one embodiment, the cataloging engine 700 mayassociate bit prints and links as groups or packaged content. Thedigital package itself my have its own bit print, as further describedherein with respect to content file bit prints and elemental bit prints.

In one embodiment, a bit print or link may be part of more than onegroup or be included in more than one content package (e.g., packagedcontent). In another embodiment, files that are part of a group orpackaged content may be separated or disassociated from the digitalpackage. For example, rights in a file that is part of a digital packagemay be sold, licensed, or otherwise transferred separate from thedigital package as a whole. For example, a user may wish to purchaserights in a section of a group of out-takes from a motion picture. Inone embodiment, the cataloging engine 700 would retrieve the bit printfor that section and pass the bit print to the arbitration engine. Inanother embodiment, if a bit print does not exist for the requestedsection, the community server or digital marketplace may request for abit print to be created for that section, in much the same manner asdiscussed herein for newly encountered files.

FIG. 8 illustrates an embodiment of a link parser 800. The link parser800 comprises a link parsing engine 802, a link database 806, and a bitprint database 804. The link parser 800 receives a link fromidentification engine (with or without an accompanying bit print) andthe link parsing engine 802 determines the number and kind ofrelationships described in the link and the linked bit prints describedin the link. In one embodiment, the link parsing engine 802 may collapsecomplex relationships and may re-assign relationships, based on the linkas provided to the link parser. For example, the link parsing engine 802may find that a reference is made to or a relationship is formed with an“intermediary bit print,” when the relationship could also be formedwith a “master bit print” (which may correspond to a “master file”designated by a publisher as an original copy or version of thecontent). In another embodiment, the link parsed by the link parsingengine 802 describes a relationship with a ghost or clone bit print,instead of a master bit print, and the relationships could be moresimply expressed if all the relationships referenced the master bitprint, rather than some bit prints referencing one or more clone bitprint(s). Thus, the link parsing engine 802 may collapse or simplyrelationships, to create relationships with a master bit print.

In one embodiment, the link parser 800 may store links in the linkdatabase 806 and may store bit prints in the bit print database 804. Inanother embodiment, the link database 806 may be used by the link parser800 as a source for information on existing links so that the linkparser may understand and simplify complex relationships as describedabove. In one embodiment, the bit print database 804 may also be used bythe link parser 800 as another source of links and relationships. Inanother embodiment, the link parser 800 may use another link databaseand or another bit print database in the digital marketplace and may nothave a link database or bit print database of its own (unlike that shownin the embodiment 800).

FIG. 9 illustrates another embodiment of a link parser 900. The linkparser 900 includes a bit print parsing engine 902, a bit print database904 and a link database 906. The link parser 900 uses the bit printparsing engine 902 to parse a bit print to find links containedinherently in the bit print itself as described above. The bit printparsing engine 902 reads a bit print and determines whether it containsany elemental bit prints. The elemental bit prints represent or areassociated with elements of a larger or parent content file. Theelemental bit prints may be known to the cataloging engine (through thecataloging engines own databases e.g., a bit print database or a linkdatabase) or generally known to the digital marketplace. In oneembodiment, the bit print parsing engine 902 may identify demarcations,segmentations, or groupings in the bit print being parsed and may decideto assign an elemental bit print to that grouping. Thus, the bit printparsing engine 902 may determine which bit prints are referencedinherently in the bit print. In another embodiment, the bit printparsing engine 902 may use the bit print database 904 as a source of bitprints with which to relate the bit print being parsed.

In one embodiment, the digital marketplace may use the cataloged bitprints stored in the cataloging engine to obtain recommendations forlike content files. In another embodiment, the digital marketplace mayuse stored bit prints for searching for content as discussed above. Inyet another embodiment, the digital marketplace may also use thecataloging engine for cross-referencing content files to enrich theexperience of a user accessing the community server. For example, thecommunity server may host a user with a subscription to content files(e.g., giving a user access to an unlimited number of content files,possibly in a certain genre, for a fixed price each month).

FIG. 10 illustrates an embodiment of a process 1000 for cataloging bitprints. The process includes receiving a bit print 1004, receiving alink 1006, parsing a link 1010, accessing a link stored in a databaseand/or a bit print stored in a database 1014. It should be noted thatlinks may be stored internally in bit prints, as discussed herein, sothe parsing may be performed on a bit print as well as a link. The bitprint may also be received 1004, not parsed by the process, and storedaccording to the parsing 1010 of the link. In one embodiment, receiving1004 a bit print and receiving a link 1006 are performed before the linkis parsed 1010. The parsing of the link 1010 may be aided by theretrieval 1014 of another bit print or link. In one embodiment, theprocess determines whether another bit print or link is desired 1012while parsing the link 1010. For example, after parsing a link ispartially completed a new link or bit print may be useful to completingthe parsing 1010. In another embodiment, determining 1012 may becompleted, another link or bit print may be accessed 1014 and a secondparsing 1010 may be initiated. After parsing the link 1010 is completed,the link may be stored 1016 and/or the bit print may be stored 1020. Thestorage of the link and/or bit print may be performed as describedherein for cataloging bit prints.

In one embodiment, the process 1000 retrieves the link and/or bit print1012 to aid in the parsing 1010 through accessing link and/or bit printdatabases. For example, a link being parsed may include reference toanother link or a bit print. The parsing 1010 may, therefore, be aidedby accessing a database 1014 to retrieve the link or bit printreferenced. In one embodiment, the parsing 1010 is performed with linksand bit prints retrieved from databases as well as a link received in1006 and/or bit print received in 1004. In another embodiment, theparsing 1010 is performed based solely on the link and/or bit printreceived. In one embodiment, the process 1000 sorts, groups and storeslinks and/or bit prints in databases (e.g., 1016, 1020) based onrelationships between the links and/or bit prints. In anotherembodiment, the process 1000 stores links and bit prints in databases(e.g., 1016, 1020) based on the order in which the links and/or bitprints are received 1004, 1006. In another embodiment, the process 1000queries whether another link and/or bit print could be used for parsingthe link 1012.

FIG. 11 illustrates an embodiment of a process 1100 for accessing bitprints and links from a catalog. The process includes receiving arequest 1104, accessing a link database 1106, accessing a bit printdatabase 1110, and transmitting a link and/or a bit print 1112. Therequest received may be any of the requests described herein sent to acataloging engine. For example, the request received 1104 may be arequest to find related bit prints or links to a provided bit print orlink. In one embodiment, the request includes a bit print. In anotherembodiment, the request includes a link describing relationships betweenbit prints. In one embodiment, the request received may be to retrieve abit print (or group of bit prints) based on a link (e.g., all bit printsrelated by the link). In another embodiment, the request may be toretrieve a link (or group of links) based on a bit print (e.g., alllinks that reference a bit print). Therefore, in one embodiment,accessing a link database 1106 and accessing a bit print database 1110may be for different purposes, depending on the request received. In oneembodiment, the process includes transmitting a bit print 1112 inresponse to the request. In another embodiment, the process includestransmitting a link 1112 in response to the request.

FIG. 12 illustrates an embodiment of an arbitration engine 1200. Thearbitration engine 1200 may be used by the digital marketplace todetermine which rights in a file are available (e.g., for sale, forlicense, or other use). The arbitration engine 1200 includes a rightsdatabase 1214, a usage database 1212, a comparison engine 1210, a bitprint database 1216, a relationship parser 1206, a request transceiver1202 and a report transceiver 1204. The bit print database 1216 may be aseparate bit print database, or a different bit print database from theother bit print databases described herein. Alternatively, the bit printdatabases described herein may comprise the same database. Those withskill in the art will further understand the various ways in whichdatabases may be distributed and/or shared.

The arbitration engine 1200 may receive requests from various parts ofthe digital marketplace, including the cataloging engine and theidentification engine. Furthermore, the arbitration engine 1200 mayreceive requests from users through the community server, or from otherentities. In one embodiment, a request received the arbitration engine1200 includes a request to determine rights used, such as rights used byindividuals on the Internet. In another embodiment, a request receivedincludes a request for the resolution of conflicts in rights. In oneembodiment, conflicts in rights may arise when a user owns rights thatare used (e.g., displayed, copied, distributed) by another individual ina manner unauthorized by the user who owns the rights. In anotherembodiment, conflicts in rights (or rights conflicts) may arise when theownership of rights in a content file is disputed between users.

In one embodiment, the arbitration engine 1200 utilizes the rightsdatabase 1214 and the usage database 1212 to determine the rights owned,the rights requested and/or the rights actually utilized to determinewhether there is a conflict and/or recommend which rights (or whichuser) should prevail. In another embodiment, the arbitration engine 1200uses the comparison engine to determine whether rights in the rightsdatabase 1214 are being violated by usages stored in the usage database1212 (or otherwise known to the digital marketplace). Usage data storedon the usage database 1212 may reflect use on a public network orotherwise known to the digital marketplace.

In one embodiment, the arbitration engine 1200 will retrieve, dependingon the request received, the rights, usages, and bit prints, relating tothat request. In another embodiment, the arbitration engine 1200 willthen send the rights, usages, and/or bit prints to the relationshipparser 1206 and the comparison engine 1210, as appropriate. For example,a request may be received for determining rights that are available andusages that exist for a certain file. In one embodiment, the arbitrationengine 1200 receives the request including a bit print associated with acontent file. In another embodiment, the arbitration engine 1200 takesthe bit print referenced in the request, searches the bit print database1216, and sends related bit prints to the relationship parser 1206.

In one embodiment, the relationship parser 1206 determines the manner(s)in which related bit prints are related. For example, the relationshipparser 1206 may determine that the bit print contained in the requestfor rights and usages is a derivative work of an original content fileand may send to the rights database 1214 and usage database 1212 the bitprint of that original content file along with a plurality of bit printsrelated to the original file. The relationship parser 1206 sends itsresults to the rights database 1214 and the usage database 1212 and thenretrieves rights granted and available for those bit prints and usagesof those bit prints (both past, present, and future usages).

The comparison engine 1210 then receives the result from the rightsdatabase 1214 and the usage database 1212. The comparison engine 1210compares the rights of all the related bit prints (e.g., the bit printssent to the right database 1214), the usages of those bit prints, and/orrights contained in the request. In one embodiment, the comparisonengine 1210 may take all the rights granted in the relevant bit printsand subtract them from the fee simple rights in the content in order toobtain the rights available. For example, if an exclusive license to allthe rights contained in all the bit prints related to an originalcontent file were granted for a limited period of time (e.g., for oneyear from the present date), then the comparison engine 1210 may returna result stating that the rights available are the fee simple rights inthe original content file (and all its derivatives) subject to thelicense.

In one embodiment, the relationship parser 1206 may be utilized by thearbitration engine 1200 to process bit prints stored in the bit printdatabase 1216 to determine which bit prints are related. For example, arequest may be received by the arbitration engine 1200 regarding aparticular bit print. Such a request may be “what are the rightspresently used for this content file?” In one embodiment, therelationship parser 1206 uses the bit print database 1216 to look up thebit print associated with the content file, as well as any related bitprints. In another embodiment, the relationship parser 1206 determinesthe relationships of the bit prints in the context of the request. Forexample, the relationship parser 1206 may determine that the contentfile was derived from another “original” content file and that there areseveral other content files derived from the original file. In oneembodiment, the arbitration engine 1200 uses the relationship parser1206 to determine whether an “original” content file is the derivationalsource for the content file requested (e.g., reformatted movie, alower-resolution image, or a derivative song). In one embodiment, therelationship parser 1206 transmits the relationships between the relatedbit prints to the comparison engine 1210, for further processing, beforethe usage database 1212, and/or the rights database 1214 are accessed.

In one embodiment, the usage database 1212 may include information thatis submitted by publishers to the community server relating to contentfiles in which the publisher owns rights. In another embodiment, theusage database 1212 may also include information that is retrievedthrough the crawler, without any input from the publisher. In oneembodiment, the usage database 1212 may also include rating informationfrom the community server. In one embodiment, this rating informationmay be submitted by users. In another embodiment, this ratinginformation may be extracted (e.g., interpreted) from searches performedby users, recommendations to other users (e.g., e-mailing of linksbetween users), and/or any other usage data perceptible by the digitalmarketplace (e.g., requests to the arbitration engine 1200 to moderatedisputes).

In one embodiment, the rights database 1214 may include informationabout rights that may be brokered (e.g., sold, licensed, or otherwisetransacted) through the digital marketplace, or may include rights thatare determined via usages in public forums (e.g., the Internet). In oneembodiment, a right stored in the rights database 1214 may be contingentupon confirmation. For example, a right may be contingent if the digitalmarketplace merely surmises the right exists because of a usage of acontent file in the public forum (e.g., via prominent display on acommercial web site over time). A contingent right may be subject toconfirmation or dispute at a later time. In one embodiment, the rightsdatabase 1214 is subject to change if, for example, the arbitrationengine 1200 determines a right associated with a particular bit print(whether or not the right was contingent) needs to be updated based onnew proof of ownership of the right. In another embodiment, the rightsdatabase 1214 contains only confirmed rights. In this embodiment, therights database 1214 could not be changed by results from the comparisonengine. In another embodiment, the rights database 1214 may be changedbased on information from the comparison engine and/or the usagedatabase (e.g., to show a potential conflict in rights).

In one embodiment, the arbitration engine 1200 may change the rightsdatabase 1214, the usage database 1212 and/or the bit print database1216 based on information received from the digital marketplace. In oneembodiment, this information is a request received by the arbitrationengine 1200 from a user or an entity inside the digital marketplace.Such a request may be for clarification of ownership rights, and mayresult in a change in the rights database 1214. For example, the crawlermay encounter a usage that seems suspicious based on a right known bythe digital marketplace, such as a content file that is being used in amanner that is inconsistent with the rights owned in that content file.In one embodiment, the digital marketplace attempts to clarify thesituation by requesting the arbitration engine 1200 to verify the usageof the content file against the rights owned in the content file. In oneembodiment, having established an inconsistency of the rights and usagesof the content file, the digital marketplace and/or the arbitrationengine 1200 may mark the rights in a digital content file as contingentor suspect. In another embodiment, the arbitration engine 1200 may markthe rights in that content file as violated. In one embodiment, based onthe change of status of the rights in the content file (e.g., contingentand/or violated), the community server may alert the owners of therights in the content file to help in the resolution of this conflict.

FIG. 13 illustrates an embodiment of a process 1300 of determining therights and usage of a content file. The process includes, receiving arequest 1302, generating a bit print, matching bit prints 1306,accessing a bit print database 1310, retrieving rights from a rightsdatabase 1312, retrieving a usage from a usage database 1314,determining a status of rights and usage 1316, and transmitting a reportof rights and usage 1320. These processes have been described in detailabove and their illustration in FIG. 13 is meant to incorporate all ofthe various embodiments described above, as well as many variationsthereof. The description of this particular embodiment is meant to addto the above descriptions of methods and systems and this embodimentshould be understood as another embodiment thereof.

In one embodiment, the request includes a bit print of a content file.In another embodiment, the request received in 1302 includes a file anda bit print is generated 1304 from the file in the request. In anotherembodiment, the request includes a link describing relationships betweenthe first bit print and other bit prints. Each of these embodiments isdescribed further herein.

The link may be used for matching 1306 a first bit print (the bit printreceived in 1302 or, alternatively, generated in 1304) to the other bitprints, including bit prints not explicitly related to the first bitprint by the link. In one embodiment, matching bit prints 1306 requiresaccessing a bit print database 1310 to retrieve similar, related orlinked bit prints to the first bit print (e.g., via a link) generated in1304 or in the request.

In one embodiment, the process 1300 determines a status of usage andrights 1316 based on the bit print and/or link provided in the requestand the status of similar, related or linked bit prints. In anotherembodiment, the process does not access a bit print database 1310 anddetermines a status of usage and rights 1316 based solely on the bitprint and/or link provided in the request.

In one embodiment, the process 1300 includes information about allrelated or linked bit prints in the report of usage and rightstransmitted 1320. In one embodiment, the process 1300 accesses the usagedatabase 1316 and stores information relating to the received request inthe usage database. For example, receiving a request for an arbitrationof rights and usage of a content file may constitute or indicate a usageof the content file.

FIG. 14 illustrates an embodiment of a process 1400 for offering forsale a pre-designated right in a content file. The process offers forsale a right in a content file with the authorization of the owner ofthe right in the content file. The owner of the right may therefore,pre-authorize 1402 that rights, which may be called pre-designatedrights, in the content file may be offered for sale under certaincircumstances. Those circumstances and the process of determining whenthose circumstances have occurred is described further below.

The owner may wish to present a right in the content file for free tousers of a publicly accessible network. It is becoming commonplace foradvertising and/or marketing to be performed over a publicly accessiblenetwork, such as the Internet. For example, marketing throughword-of-mouth based on free uses, or so-called “viral marketing,” may beused by owners of rights in a content file to raise market interest inthe content file or other files of the owner. In some instances,however, after giving away a right in a content file, an owner may wishto sell a right in that content file or another content file. Thepopularity of the content file may bolster the marketability of anotherright in the same content file or of a right in another content file.Therefore, the process 1400 may present a free right in a content fileand, based on certain criteria discussed below, automatically offer forsale a right in the content file.

In the embodiment shown, authorization is received 1402 from the ownerof a right in a content file. The authorization is limited to the rightsin the content file which are owned by the owner. For example the ownermay own a master right in the content file. A master right may allow theowner to distribute non-exclusive licenses in the content file, as wellas similar licenses in all related content files. One example of amaster right is the entire bundle of rights in a copyright owned by anoriginal creator of a piece of media or content. Another example of amaster right is an exclusive license in a content file which allows forcontrol over distribution.

Authorization may be received 1402 from an owner to distribute a freeright in the content file on a free basis to the public. For example, anowner of an image file may authorize a community server to display theimage file publicly on a network, in a certain resolution and withcertain protections or watermarks (e.g., copyright notice, the word“proof”). Authorization may be received 1402 from the owner to offer forsale the right or another right in the content file or a right inanother content file based on certain criteria being met. For example,if the content file is rendered, for example, an image file is viewed, asong/video is played a certain number of times within a given timeframe, or by a certain number of different users. Other criteria will bediscussed below.

The owner's authorization received may include many differentpre-designated rights to be offered for sale based on different criteriabeing met. In addition, different prices may be requested by the ownerfor the different pre-designated rights or based on different criteriabeing met. For example, one pre-designated right in the content file maybe offered for sale for one price in response to one criterion beingmet, and, in response to another criterion being met, the same oranother pre-designated right in the content may be offered for sale forthe same or a different price.

In one embodiment, each content file discussed with respect to FIG. 14may be a different content file. For example, a first content file maybe a display content file, such as a thumbnail, a trailer, or a lowresolution content file. A second content file may be a full-lengthcontent file, a commercial free content file, or a high resolutioncontent file. The same right or a different right may be sold in thesecond content file while the right is given away for free in the firstcontent file. For example, an owner may wish to entice users with acontent file (e.g., edited or lower resolution version) so that theusers will want to buy a right in another content file (e.g., higherresolution or unedited version).

In another embodiment, each content file discussed with respect to FIG.14 is the same content file. For example, a single content file could beused to market or advertise the sale of a right in the content file. Aright may be given away for free or otherwise used by a user withoutother rights (e.g., rights which an owner hopes to sell) being able tobe used. DRM software/hardware may restrict the use of different rightsin the same file. For example, one key/password may allow use of a firstright in the content file and another key/password may allow use of asecond right in the same content file. Other DRM techniques are known tothose with skill in the art and may be used.

In one embodiment, a content file may be received from the owner. Theowner may upload a file to the community server for presentation of afree right in the content file and the offering for sale of apre-designated right in the content file. In another embodiment, thecommunity server may create different versions of the content file. Anowner may be able to upload an unprotected, high-quality version of acontent file, and then different content files embodying differentformats may be created (e.g., by the community server or a DRM enginetherein) to limit use to the free right in the content file asauthorized by the owner.

In one embodiment, the different content file is a differently-formattedversion of the content file. For example, the different content file maybe a related content file (as described further herein) containing thesame content, only at a different resolution. The owner may uploaddifferent content files for public presentation of the free right thanfor offering for sale of the pre-designated right. The different contentfile may be another version of the content file, such as a DRM-protectedversion or otherwise protected version.

The process 1400 presents a content file 1404 for the use of a freeright. The free right may be offered to the public, such as the group ofall registered users of a community server. The free right in thecontent file may also be presented to a user who selects the file forviewing or otherwise rendering. The free right in the content file maybe accessed by the public with the access via being searchable by thepublic. For example, a user may search using a keyword or tag and mayselect the content file from among the results of the search. The freeright in the content file may then be presented to the user. Othermethods of presenting files and rights in the files are known to thosewith skill in the art.

A popularity index of a content file may be calculated 1408 to determineif a criterion is met, in order to determine whether to offer for sale aright in a content file. For example, a criterion may be a popularityindex exceeding a threshold, as discussed further below. A popularityindex is not limited to types of data which indicate a “popular” contentfile, such as voting, ranking, rating, or other subjective data given bya group of users. Calculating a popularity index 1408 may take intoaccount any of these data, and may use data compiled from objectivemeasures, such as usage data. Usage data of several types may be used indetermining a popularity index of a content file, and are discussedfurther herein.

A popularity index calculated in 1408 can be represented in many forms.For example, a popularity index may be a scalar number, a vector, agroup of numbers, an array, or a plurality of scores in a plurality ofcategories. A popularity index may be calculated 1408 in a form with acombination of forms, such as a popularity index comprising a digitindicating whether a request to buy a right in the content file has beenreceived in the last week, an aggregate average of number of viewsweighted by ratings related to those views, and a derivative of theaggregate average over the last week.

A threshold may be represented in any of the forms of the popularityindices. In addition, the comparison of a popularity index and athreshold may be more than a simple scalar comparison of which isgreater. The comparison may include a comparison of categories,weighting or other statistical techniques known to those skilled in theart.

A popularity index may be calculated 1408 in a form to match the form ofa threshold against which popularity index may be compared 1410. Forexample, if a threshold has an array of numbers, the popularity indexcould have an array of numbers. A popularity index and a threshold maybe compared even if they are of dissimilar forms, for example, throughusing categories of the forms which are similar.

The following discussion of how a popularity index is calculated shouldbe understood also to apply to the calculating of a threshold. In oneembodiment, a threshold may represent a time-delayed or otherwisemodified popularity index, which when compared to a popularity index maybe used to determine whether a criterion has been met. For example, acriterion may be that usage data of a file is increasing at a particularrate within a particular group of usage characteristics. In this case, athreshold may be composed of one or more past popularity indices.

A popularity index may be calculated 1408 at any time, based on events,or periodically updated. For example, a popularity index may becalculated 1408 whenever usage data are updated (e.g., usage data onwhich the popularity index depends). A popularity index may becalculated 1408 when a request for buying a right in content file isreceived. A popularity index may be calculated 1408 when a triggeringevent is detected. The triggering event may be an event on a publiclyaccessible network (e.g., a content file being on a “Top 100” list, thefile being mentioned on a particular website). A triggering event may adetected use by a user (e.g., through searching the playlist of theuser). For example, a use by a user may be detected based on informationstored on a user's perception device (e.g., a media player, a portablemedia device).

In one embodiment, a popularity index is calculated 1408 in response tomatching an unknown file to a content file 1406. For example, data usedin creating the popularity index may be retrieved and compiled after thematching 1406. The matching operation 1406 may provide data for thecalculating of the popularity index 1408, as will be described furtherbelow. In another embodiment, the popularity index calculated in 1408has been created in advance of the matching operation. For example,popularity indices may be created, updated and stored in an on-goingbasis.

A popularity index and/or a threshold may be set by informationautomatically compiled by a computer, a digital marketplace or acommunity server. The breadth of data used may include any pertinentdata known by such a computer, digital marketplace or community server.

The process of calculating 1408 a popularity index may weight data inseveral manners. For example, more recent information may be weightedmore heavily than less recent information. Data associated withpurchases and sales (e.g., ratings associated with sales) may beweighted more heavily than data relating to ratings, usages, or requestsnot associated with purchases or sales. Data associated with registeredusers (e.g., data created by activities of registered users) may beweighted more heavily than data not associated with registered users.Data relating to a registered user may be normalized with respect to theuser's other activities. For example, a user who often gives a poorrating to a particular type of content file may have his ratings ofcontent files normalized to reflect that fact. Those with skill in theart will be aware of several methods of adjusting data based on otherdata, such as statistical methods of normalization.

Data used for calculating a popularity index in 1408 may include dataabout the content file and/or about other content files. The data may berelated to ratings of a content file, ratings of related content files,ratings of commonly-owned content files (e.g., owned by the same owner).The data may be collected from files known to be related to the contentfile and from files determined to be related to the content file. Otherfiles may contribute several types of data, including usage data,ratings data, user information associated thereto (e.g., weighing theratings of various users), numbers of related bit prints, requests topurchase the content file and/or the related files, and ratings ofcommonly-owned content files.

These data from other content files may be compared to, combined with,or modified by data associated with the content file for which thepopularity index is being calculated. For example, data used tocalculate a popularity index 1408 for a content file may be normalizedto reflect data of other (e.g., related) content files. Data may beretrieved from another source, or may be stored locally. Any other dataknown to digital marketplace as described further herein may be used tocalculate a popularity index 1408.

Usage data of an unknown file may be used after it is matched 1406 tothe content file for which a popularity index is calculated 1408. Suchdata may be used in addition to the usage data of the content file. Forexample, an unknown file may have usage data from uses occurring beforethe unknown file is matched 1406 to the content file. The process ofmatching files is described in detail (e.g., using bit prints) furtherherein.

An owner who is requesting that a right in the content file be offeredfor sale based on the comparison of a popularity index and a thresholdmay influence how the popularity index and/or the threshold iscalculated. In one embodiment, the owner may assist or guide thecalculation of a popularity index (and/or threshold). The owner may beable to design how a popularity index (and/or threshold) is calculated.For example, the owner may be able to submit information which should betaken in to consideration for the calculations. The owner may submittypes of usage data, other files, attributes, or other data which hebelieves should be used in creating a popularity index. The owner maysubmit desired threshold(s) associated with a popularity index. Theowner may submit desired ways of calculating thresholds. Data submittedby an owner may be used to create the process of calculating apopularity index and/or a threshold.

An owner may wish to create different popularity indices associated withdifferent rights in the content file. An owner may wish to have adifferent threshold for each popularity index. Therefore, for aparticular content file, there may be many popularity indices andthresholds which are compared in order to trigger the sale of rights inthe file. For example, a threshold may be associated with a right for asingle use of a content file, another threshold may be associated with aright to use the content file as reformatted or remixed withadvertisements, and another threshold may be associated with a right touse the content file for personal use (e.g., copying to differentdigital media players, burning to a CD or DVD).

In one embodiment, a right may be received along with a threshold fromthe owner. In another embodiment, a right may be selected to be sold bythe owner and the threshold and popularity index associated with sellingthat right may be calculated on behalf of the owner based on data knownto a community server as discussed herein.

An owner may wish to see popularity indices and thresholds which wouldbe calculated based on his guidance in order to confirm that hisguidance will create the appropriate popularity indices and thresholds.In one embodiment, rights and associated popularity indices andthresholds are returned to the owner for review. Hypothetical scenariosin which the thresholds would be met or satisfied, and suggested pricesfor the rights to be offered for sale upon meeting the thresholds mayalso be returned to the owner.

Based on a comparison of a popularity index 1410 with a threshold, aright may be offered for sale 1412. In the embodiment shown, thepopularity index is compared to the threshold 1410 and, if thepopularity index is determined to be greater than the threshold, a rightis offered for sale 1412. However, as described above, the popularityindex and the threshold may be more complex than scalar numbers andcomparing them may be more complex than determining which is greater.

Offering for sale 1412 a right in the content file may be performed to asingle user, a group of users, or to the public over a publiclyaccessible network. For example, a right in a content file may beoffered to registered users of a community server or to the generalpublic including users who are not registered users of a communityserver. Offering for sale 1412 a right in the content file may beperformed in any of several manners, including ways commonly known orknown to those skilled in the art.

After a right in a content file is offered for sale 1412, thedistribution of the free right in the content file may be limited 1414.In one embodiment, if the free right had previously been offered forfree public use, the free right may no longer be made available. Inanother embodiment, another free right in the content file (or in arelated content file) may be offered for free public use. In anotherembodiment, the free right in another content file may be offered forfree public use. The other content file may be a modified version of thecontent file. For example, the modified version may includeadvertisements, may be an edited version of the content file, or may bemixed with yet another content file (thereby providing an opportunity tocross-market two content files).

FIG. 15 illustrates another embodiment of a process 1500 for offeringfor sale a pre-designated right in a content file. The process includesreceiving authorization from an owner 1502 to present a free right in acontent file 1504. Authorization may also be received 1502 from an ownerto offer a right (e.g., a pre-designated right) for sale based on a userrequesting to purchase that right in the content file or another rightin the content file. These operations are further described above withrespect to FIG. 14.

A request received from a user 1506 to purchase a right in the contentfile triggers similar processes as those discussed in FIG. 14 withrespect to comparing a popularity index with a threshold. However, theright requested by a user may not be designated by the owner as a rightwhich should be offered for sale. Therefore, the right request ischecked 1510 against rights authorized 1502 by the owner for sale.

If there is a match between the right requested by the user in 1506 andthe right(s) authorized by the owner in 1502 to be offered for sale, theright requested in 1506 may be offered for sale to the user 1512.Imperfect matches between the right requested and the right authorizedmay also lead to offering for sale the authorized right in the contentfile.

In addition, the user may request the sale of a right, yet leave theright unspecified in his request. In this case, a right may be inferredfrom the request. For example, a default right (such as a non-exclusivelicense to render the content file from a remote location) may beinferred. As another example, a right may be selected from among therights authorized to be sold in the content file.

Offering for sale 1512, 1514 a right in the content file may beperformed to the user who requested the sale of the right 1512, to agroup of users (including the user who requested the sale), or to thegeneral public over a publicly accessible network 1514. For example, aright in a content file may be offered for sale 1514 to registered usersof a community server or to the general public including users who arenot registered users of a community server. Offering for sale 1512, 1514a right in the content file may be performed in any of several manners,including ways commonly known or known to those skilled in the art.

As described herein, functional elements being performed by a single ormultiple components, in various combinations of hardware and software,and individual functions may be distributed among functional elements ateither the client or server level. In this regard, any number of thefeatures of the different embodiments described herein may be combinedinto one single embodiment and alternate embodiments having fewer thanor more than all of the features herein described are possible.Functionality may also be, in whole or in part, distributed amongmultiple components, in manners now known or to become known. Inaddition, elements of the systems described herein may be distributedgeographically or functionally in any configuration.

Elements of the systems described herein may be implemented in hardware,software, firmware, any combination thereof, or in another appropriatemedium. Thus, myriad software, hardware, and/or firmware combinationsare possible in achieving the functions, features, interfaces andpreferences described herein. The systems described herein may implementany part of the methods described herein. In addition methods describedherein when implemented in hardware, software, firmware, any combinationthereof, or in another appropriate medium may form any part of thesystems described herein. Therefore, the descriptions of the methods andsystems herein supplement each other and should be understood by thosewith skill in the art as forming a cohesive disclosure.

The methods described herein may be performed iteratively, repeatedly,and/or in parts. In addition, some of the methods or parts of themethods described herein may be performed simultaneously.

1. A method comprising: presenting, via a community server comprising atleast one processor, a free right in a first content file for public useover a publicly accessible network; collecting overall current datausage of the first content file by a plurality of users on the network;calculating, via the community server, a popularity index for the firstcontent file based on the collected overall current usage data of thefirst content file, said calculating comprises weighing the usage dataaccording to individual designations of each of the plurality of users,the usage data comprising all data statistically related to metadata ofthe first content file; and based on a comparison of the popularityindex for the first content file with a threshold, wherein saidcomparison comprises determining that the popularity index exceeds thethreshold, and wherein said comparison comprises categorically comparinga form of the popularity index and a form of the threshold, offering forsale, via the community server, on the publicly accessible network apre-designated right in a second content file, wherein thepre-designated right in the second content file is a right in the secondcontent file authorized by an owner to be offered for sale, wherein theowner owns a master right in the first content file and the master rightin the second content file, the master right including a right todistribute the free right and a right to distribute the pre-designatedright.
 2. The method of claim 1, wherein the free right in the firstcontent file is a right to access the first content file in a firstformat and wherein the pre-designated right in the second content fileis a right to access the second content file in a second format.
 3. Themethod of claim 1, wherein the free right in the first content file is aright to render the first content file from a remote location andwherein the pre-designated right in the second content file is a rightto copy the second content file to a permanent computer-readable medium.4. The method of claim 1, further comprising: selecting thepre-designated right from a plurality of different pre-designatedrights, wherein each of the plurality of different pre-designated rightsis a different right authorized by the owner to be offered for sale inthe second content file.
 5. The method of claim 1, further comprising:receiving the second content file from the owner; and receiving arequest from the owner to present for public use on the publiclyaccessible network the free right in the first content file.
 6. Themethod of claim 1, wherein the usage data of the first content file aredata selected from user requests for the first content file, userratings of the first content file, and user ratings of a differentcommonly owned content file.
 7. The method of claim 1, furthercomprising: limiting distribution of the free right in the first contentfile based on the comparison of the popularity index with the threshold.8. The method of claim 1, further comprising: receiving an unknown file;and matching the unknown file to the second content file.
 9. The methodof claim 8, further comprising: calculating the popularity index inresponse to matching the unknown file to the second content file. 10.The method of claim 9, wherein calculating the popularity index isperformed based on unknown file usage data.
 11. The method of claim 10,wherein the unknown file usage data includes user requests for theunknown file.
 12. A method comprising: presenting, via a communityserver comprising at least one processor, a free right in a firstcontent file for public use on a publicly accessible network; receiving,at the community server, a request over the publicly accessible networkfrom a user to purchase a first right in the content file receiving,from an owner, a request to offer the first right in the content filefor sale based on receiving the request from the user to purchase thefirst right in the content file, wherein the receiving the request fromthe owner is performed before the receiving the request from the user;determining, via the community server, whether the first right in thecontent file is authorized by the owner to be offered for sale andwhether metadata of the content file satisfies a statistical thresholdbased upon a determination relating to all data statistically related tothe content file metadata, said metadata being weighted according todesignations of the user, wherein the owner owns the first right in thecontent file; and if the first right is authorized by the owner to beoffered for sale and the statistical threshold is satisfied, whereinsaid authorization comprises categorically comparing a form of the datastatistically related to the content file metadata and a form of thethreshold, offering, via the community server, the first right in thecontent file for sale to the user over the publicly accessible network,wherein the owner owns a master right in the content file, the masterright including a right to distribute the free right and a right todistribute the first right.
 13. The method of claim 12, wherein thefirst right in the content file is a right to access the content file ina first format and wherein the free right in the content file is a rightto access the content file in a second format.
 14. The method of claim12, wherein the first right in the content file is a right to render thecontent file from a remote location and wherein the free right in thecontent file is a right to copy the content file to a permanentcomputer-readable medium.
 15. The method of claim 12, furthercomprising: offering the first right in the content file for public saleon the publicly accessible network.
 16. The method of claim 12, furthercomprising: limiting distribution of the free right in the content filebased on the receiving the request from the user.
 17. A systemcomprising: a community server comprising at least one processor whichpresents a free right in a content file for public use on a publiclyaccessible network; a cataloging engine, implemented by the communityserver, which collects current overall data usage of the content file bythe plurality of users on the network, and calculates a popularity indexfor the content file based on the overall current usage data of thecontent file, said calculating comprises weighing the usage dataaccording to individual designations of each of the plurality of users,the usage data comprises all data statistically related to metadata ofthe first content file; wherein the community server offers for sale onthe publicly accessible network a pre-designated right in the contentfile based on a comparison of the popularity index of the content filewith a threshold, wherein said comparison comprises determining that thepopularity index exceeds the threshold, and wherein said comparisoncomprises categorically comparing a form of the popularity index and aform of the threshold, wherein the pre-designated right in the contentfile is a right in the content file authorized by an owner to be offeredfor sale, wherein the owner owns a master right in the content file, themaster right in the content file including a right to distribute thefree right in the content file and a right to distribute thepre-designated right in the content file; and an arbitration enginewhich selects the pre-designated right from a plurality of differentpre-designated rights, wherein each of the plurality of differentpre-designated rights is a different right in the content fileauthorized by the owner to be offered for sale.
 18. The system of claim17, wherein the community server receives a request from a user to buythe pre-designated right in the content file; and wherein the communityserver presents for sale on the publicly accessible network thepre-designated right in the content file based on the request received.19. The system of claim 17, wherein the first right in the content fileis a right to access the content file in a first format and wherein thefree right in the content file is a right to access the content file ina second format.
 20. The system of claim 17, wherein the first right inthe content file is a right to render the content file from a remotelocation and wherein the free right in the content file is a right tocopy the content file to a permanent computer-readable medium.
 21. Thesystem of claim 17, wherein the community server receives the contentfile from the owner; and wherein the community server receives a requestfrom the owner to present for public use on the publicly accessiblenetwork the free right in the content file.
 22. The system of claim 17,wherein the usage data of the content file are data selected from userrequests for the content file, user ratings of the content file, anduser ratings of other content files associated with the owner.
 23. Thesystem of claim 17, wherein the community server retrieves usage data ofthe content file from a database selected from a ratings database, auser information database, and a metagraphics database.
 24. The systemof claim 17, wherein the community server limits distribution of thefree right in the content file based on the comparison of the popularityindex with the threshold.
 25. The system of claim 17, wherein thecommunity server receives an unknown file, the system furthercomprising: a comparison engine which determines whether the unknownfile is related to the content file based on matching a bit print of theunknown file and a bit print of the content file.
 26. The system ofclaim 25, wherein the cataloging engine calculates the popularity indexif the unknown file is related to the content file.
 27. The system ofclaim 26, wherein the cataloging engine calculates the popularity indexbased on unknown file usage data.
 28. The system of claim 27, whereinthe unknown file usage data includes user requests for the unknown file.